Mobility on Demand and Paratransit Software Platform

The Vendor is required to provide a modern, scalable, creative, and highly functional software solution with the capacity of reserving trips, dispatching trips, managing passenger eligibility and optimizing trips for improved efficiency and customer satisfaction.
- Previous industry software has been specialized to one type of transportation, the authority requires a software that can comingle various types of trips, passengers, fare types and services:
• Paratransit
• Mobility-On-Demand (MOD)
• Deviated Fixed Route (Flex)
- Optional Services
• Fixed Route
• Autonomous Vehicles
• Other Current or Future Transit Services as needed
- Services include:
• Modern Technology
• Certification/Eligibility, Client Management
• GIS and Mapping Functions
• Reservations
• Scheduling
• Dispatch
• Reporting
• Mobile Data Terminals
• TNC/Provider Integration
• Maas Integration
• Inbound / Outbound IVR / Communications
1. Modern Technology
- Code Base
• All code and protocols utilized from front end, middleware, and backend, must be such that is currently in use; these are languages and technologies typically found in job postings today; this will allow the awarded vendor to find additional programmers or developers if the awarded proposer requires them; older languages and protocols such as cobol, delphi, visual basic 6, xml, and ODBC should not be utilized; proposers must describe the software stack they use, including applicable protocols to assure agency is purchasing said modern technology.
- Processor and memory
• All systems utilized should have full capacity for hyper threading and modern utilization of memory; this means, no core functions, servers, or executables may rely on single threaded processing or older memory items such as 32-bit drivers; proposers are to affirm that their entire software stack is modern in nature and should describe a typical server setup being proposed for the agency.
- Encryption and security
• Encryption must be utilized at least 256 AES; proposers are to list any security certifications held that are currently valid.
- Multifactor authentication
• For privacy and security purposes, proposers are to have authentication for the proposed system. if multiple options are available, they are to be listed and described.
- Front end user and admin screens – web based
• agency requires that all screens used by reservationists, customer service staff, dispatch, management, and administrators are web-based, meaning the system should not require citrix, remote desktop, specific operating systems, or applications or executables to be loaded, installed, or maintained by agency or the awarded proposer; web based access should have SSL enabled by default. if any screens are not accessible via smaller devices like tablets or smartphones, the proposer should outline them in the response to this section; system should be hosted by high availability companies such as azure, google cloud, etc.
- Initial heightened customer support
• For a one (1) month period, the proposer shall provide an intensified level of support for the system; as part of this heightened customer support, the contractor shall arrange for its personnel to be present daily at agency's premises for a duration of twelve (12) hours, from 7 am to 7 pm, Monday through friday (remote availability on the weekends); agency shall allocate office space for such personnel; the proposer shall supply all necessary equipment to facilitate the provision of heightened customer support.
- Production and testing / training environments
In addition to the software production environment, the proposer shall provide and make available for select staff the following environments for the system:
• Test environment: a test environment that fully parallels the production environment, this will include test data that parallels production data and enables the validations of all updates to the system and other agency-approved modifications.
• Training environment: a training environment that fully parallels the production environment, which training environment shall include training data that parallels production data and enables agency to train end-users.
• Note: the test and training environment may be the same; however, proposers should explain how they advise agency to use if testing and training simultaneously.
• Proposers must provide 24/7 support to users of this platform; an email address will not be sufficient; a person must be available to receive calls regarding system issues at all times.
AI or machine learning
• Proposers are to describe their approach to machine learning, predictive analytics or AI, and how it applies or will apply to this contract.
2. Certification eligibility platform/client management
- Eligibility status
• Software should be able to track client eligibility status for ADA, transportation disadvantaged funding purposes and/or other eligibility characteristics per agency’s direction, including the initial eligibility approval process with documentation and the client’s eligibility start and end date. transportation disadvantaged service pertains to those trips that’s origin and/or destination is outside of the ¾ mile ADA buffer for systems with traditional ADA services.
Eligibility-related trips
• System should provide the option to book a trip for a potential client who is setting up an appointment for an in person interview for eligibility.
- Client type
• Users should have the ability to enter both ADA and non-ADA clients into the system.
- Build new client database files
• The selected proposer, as soon as practical after notice to proceed from agency, shall be responsible for providing a data “template” for staff to begin compilation of information necessary to complete the client database elements required for use in scheduling, trip assignment, and reporting.
- Data conversion of existing database
• The selected proposer, as soon as practical after notice to proceed, will evaluate current database, currently hosted by trapeze, and develop appropriate data conversion process that converts existing information into a compatible format for use in the scheduling and dispatching system solution.
- Database attributes
• The client database shall be capable of providing a full range of data elements for each client in the system.
Information shall include, at a minimum, full identification including gender, address, contact details, third party/emergency contacts, disability status, mobility aides used, required accommodations, caregiver, language spoken by client, program affiliation, and payee options including third-party contracts.
- Customer look-up
• the customer database shall provide functionality to allow customer service agents to readily look-up client records for edit, trip-booking, etc. search capabilities should be based on customer name, and identification number, phone number, or similar characteristic; when looking up a customer, auto-complete features should be utilized to minimize user input.
New client entry/customer edits
• System shall be capable of registering new clients, capturing information about addresses, phone number, email address, favorite destinations, disability type (if any), space requirement, load/unload time, fares, payment options, eligibility conditions, funding sources, etc. while a customer service agent has the new customer on the telephone.
- Customer edits
• The system shall permit editing of all fields in a customer record in a real-time basis and shall permit suspension (temporarily) of service; if information is updated, such as client addresses or cell phone numbers, future trips should be updated with new information without requiring further action by agent.
3. GIS and mapping functions
- General
• Agency requires that proposers provide modern GIS functionality in the solution being proposed. the map displayed to reservationists, customer service agents, dispatchers, and drivers is to be provided by one of the industry leading map providers, i.e., google maps, map box, here, etc. new shopping centers, streets, and other common locations that are readily available on these mapping systems should not require a map upgrade to be needed for these new points to be added to the system map.
Service area(s)
• Agency requires that the service area boundaries be readily identifiable and graphic, or query functionality must be present to determine if requested trip origins and destinations are within service area(s); the ability to edit service area boundaries and set custom geofencing should be readily part of the existing features; thus includes the ability to allow custom fare collections by and between multiple service areas and service types, as required by agency.
- GIS functionality
• the system must incorporate GIS capabilities and allow user access to map views of the service area; individual routes or runs, and/or stops; specific street address; or other specified user-defined zoom levels; panning/zooming shall be incorporated into the mapping capabilities.
- Export of map data
• The system shall be capable of exporting data and related geospatial information to other software platforms; data shall be exportable to at least standard GIS formats like shapefiles, geojson, or geodatabase.
Map features and attributes
• Access to maps must be seamless from within the scheduling software (e.g., user should be able to view a map with single mouse click or menu selection).
• Base maps must contain current attributes on street segments, addressing, speed limits (if available), etc. offeror shall be responsible for supplying a fully up-to-date map complete with all attributes necessary for point-to-point scheduling using street level routing geography (not zones); street network shall permit definition of segment characteristics, such as speed limits, one-way direction, etc.
• GIS functionality shall include the ability to develop overlays or coverages of municipal boundaries and other key geographies.
• GIS functionality shall include the ability to define service-based zones, such as fare zones, etc.
• System shall permit definition and display of physical features that function as barriers to transportation.
• The system must be capable of importing agency fixed route GTFS and/or GTFS-RT file data with the routing info. fixed routes data must be available both for with the ability to compare paratransit trips to fixed route for equivalency (via built in reporting), as well as providing options for clients to see if and when they can transfer to and from fixed route pickup addresses and/or mobility-on-demand service.
• system shall be capable of defining and displaying point files, indicating system time points, bus stops, major intersections, major transfer points, and major destinations of travel, or other points of interest.
Geocoding
• Service area map shall contain definitions of street segment name and address ranges; system shall have full geocoding capability allowing agency staff to enter an address and locate the address on the map; system shall be capable of handling various abbreviations of names (e.g., St. for street, etc.) in the geocoding process; addresses should self-populate as the user types the beginning of the address, based on addresses in the local area.
• System shall permit manual assignment of x- and y- coordinates in the event an address cannot be geocoded based on existing map address range attributes.
Distance computation
• System shall have the capability to use street level GIS map data speed to calculate actual driving speed and distance duration during the booking/reservation and scheduling process (based on historical and/or live data).
• System will also have the capability to use the street GIS level map data to identify one-way street information while calculating drive distance and time.
4. Mobility-on-demand reservations/scheduling
- Real time trip entry
• System shall permit real-time trip booking by multiple means – online, through a mobile application, and on the phone through an agency reservationist; similarly, reservations creation must be available to clients via an app as well as webpage.
• System must be capable of processing subscription trips (standing orders), demand response trips scheduled in advance, and real-time trip requests; the software must be capable of processing, scheduling, and dispatching different trip types without manual intervention.
• The system shall optimize mobility solutions throughout the operating day; it will have the ability to recommend assignment of a requested ride to fixed route based on rules determined by the agency.
- Pick-up time, appointment time, and allowances
• System shall be capable of scheduling based on requested pick-up time or customer appointment time and shall consider appropriate travel time to ensure on-time arrival at a destination.
• System shall be capable of incorporating a user-specified policy on pick-up time negotiation with the client; system must be capable of incorporating multiple policies.
• Users should be capable of requesting a ride by responding to a series of prompts about their travel, the system shall provide date, time, location of pick-up, date, time, location of drop-off, transfer connection information (if applicable), and associated cost of the complete trip (total fare).
- Advance reservations
• System shall be capable of accepting trip reservations for a period of at least up to 14 days in advance of the requested trip date; system should have the capability of adjusting this parameter.
- Service zones and stops
• System shall be able to recognize multiple service zones specified by the agency, which can be edited by agency system administrators.
• System must be able to assign vehicles to zones based on anticipated usage algorithms in order to accommodate anticipated real-time trip request volumes.
• If directed by agency, system will be capable of designating stops or virtual stops within or outside designated zonal boundaries as designated pickup locations or locations to apply different fare rules to encourage usage of service as a first- and last-mile service for fixed route bus.
Trip reservation editing
• System shall provide means for a customer or customer service representative to access existing trip reservations easily and quickly in order to edit travel destination, trip dates, and/or travel times prior to start of a customer’s trip or during a trip in the event of unforeseen circumstances.
• System shall permit multiple cancellation types as required by agency, of any trip in the system.
• System shall maintain a cancellation record, by client, to facilitate system management of sanctions for excessive customer abuse of cancellation policies.
Trip cancellation
• System shall provide methods to enable customer or customer service agents to easily retrieve an existing trip reservation and, upon customer request, cancel the reservation.
Vehicle assignment
• In assigning passengers to vehicles and/or vehicles to system runs, system shall be capable of recognizing the need for accessible vehicles, vehicle capacity, etc., in making said assignments; system shall be able to assign vehicles to zones or other geographic locations/boundaries.
Editing schedules
• System shall be capable of adding trips to a previously generated schedule or re-assigning trips from one run to another in dynamic fashion.
• System shall be capable of evaluating individual trip parameters and select runs that best satisfy the requirements of the reservation while maintaining the integrity of existing reservations on the same run. If system generates a range of alternatives, system shall present alternatives in rank order with the highest ranked alternative in dictating the “best” selection; the best selection will be chosen based on vehicle GPS of current vehicles on the road (in the case of same day trips) and the information of other trips currently within the schedule for the time that the trip in question is being booked.
• The system shall permit the system administrator to set and modify scheduling parameters to optimize service performance and service quality – factors such as time-on-board, productivity (boarding’s per revenue-hour, grouping trips), travel time, service costs, costs per passengers served, time between trip request and vehicle arrival, time between requested drop-off and actual drop-off, and colocation of riders at virtual stops.
Dynamic flex schedule
• The system shall permit the system administrator to set and modify scheduling parameters to optimize service performance and service quality – factors such as time-on-board, productivity (boarding per revenue-hour, grouping trips), travel time, service costs, costs per passengers served, time between trip request and vehicle arrival, time between requested drop-off and actual drop-off, and colocation of riders at virtual stops.
• The system shall facilitate the dynamic flex service model during times of peak travel demand, particularly when there is a majority-skewed directionality of travel; the SaaS platform shall tune service parameters to optimize loadings (vehicle utilization) and instruct riders to predetermined pop-up bus stops (virtual stops) to facilitate fewer pickups and drop-offs and a more direct routing to the common destination (mobility hub).
5. Reservations – paratransit
- Trip details entry
• System shall permit trip booking while transit personnel are on the phone with the client/customer. Similarly, reservations creation must be available to clients via an app as well as webpage.
• System must be capable of processing both subscription (standing orders) and demand response trips in this manner.
• System shall be capable of processing, scheduling, and dispatching same day trip orders without the need for manual intervention from users.
• System shall permit reservation staff to access client records by entering client last name and first name, telephone number, or other id number.
• System will have the capability to automatically populate the reservation screen with the customer data, including commonly used locations, mobility device, eligibility, PCA, etc. after the individual has been identified.
Default and common pick-up address
• System shall default to the client’s home address as the pick-up location.
• System shall provide the ability to enter alternative addresses through key stroke entry, through use of list boxes, pop up window, or other means of alternative pick-up addresses associated with that client (e.g., common travel destinations of that customer).
Client trip destinations
• System shall be capable of displaying, through keystroke or mouse click, pop-up window, list box, or similar alternative, a list of most frequent client travel destinations and/or recent destinations of travel for easy insertion into the destination field; user must be able to select destinations from these fields and populate trip destination fields through this selection process.
- Return trips
• System shall be capable of automatically generating the return trip from the originating trip destination to trip origin.
- Pick-up time, appointment time, and allowances
• System shall be capable of scheduling based on requested pick-up time or customer appointment time and shall consider appropriate travel time to ensure on-time arrival at a destination.
• System shall be capable of incorporating a user-specified policy on pick-up time negotiation with the client; system must be capable of incorporating multiple policies.
• Trip request should be made available via mobile application, web portal, call center and any other options.
• Users should be capable of requesting a ride by responding to a series of prompts about their travel, the system shall provide date, time, location of pick-up, date, time, location of drop-off, transfer connection information (if applicable), and associated cost of the complete trip (total fare).
- Advance reservations
• System shall be capable of accepting trip reservations for a period of at least up to 14 days in advance of the requested trip date; system should have the capability of adjusting this parameter.
- Standing order trip entry
• System shall be capable of accepting standing orders; system shall permit day of the week type travel dates and monthly calendar-based travel dates, (e.g., first and third Wednesday of each month).
• System shall be capable of setting finite limits on the length of subscription orders; systems shall permit transit personnel to “turn off,” on a temporary basis, a client’s standing order; system shall permit entry of both a start date and end date of the time period when the client will not take the standing order trip.
- Trip reservation editing
• System shall provide means for a customer or customer service representative to access existing trip reservations easily and quickly in order to edit travel destination, trip dates, and/or travel times prior to start of a customer’s trip or during a trip in the event of unforeseen circumstances.
• System shall permit multiple cancellation types as required by agency, of any trip in the system.
• System shall maintain a cancellation record, by client, to facilitate system management of sanctions for excessive customer abuse of cancellation policies.
- Suspended service
• System shall be able to temporarily suspend a client’s service eligibility; system shall permit entry of both a start date and end date of the time period when the client’s ridership privileges are suspended; during this period, the system shall not permit trip booking without supervisor permission.
• System shall have provisions, in the event an individual customer’s service is temporarily or permanently suspended, to display a warning alert or physically block a reservation agent from booking a suspended client’s trip.
• System shall be capable, during the course of the reservation entry process, of allowing client or customer service agent to add one (1) personal care attendant (PCA) or companion to the trip request.
• Optional: system should have capability of designing warning and suspension letter to send printed or electronic copy to customers.
- Future computation
• System, at trip booking's end, shall confirm the booking with fare(s), if applicable, to be paid by the user(s), and companion, identified PCA is not charged for trip.
- Trip cancellation
• System shall provide methods to enable customer or customer service agents to easily retrieve an existing trip reservation and, upon customer request, cancel the reservation.
6. Scheduling - paratransit
• System must have built in ability to ‘comingle’ or group trips of different service types together in an efficient manner.
• Core functionality must include ability to manage scheduling of paratransit, mobility-on-demand, and other services as required by agency, IE flex service.
• System shall have capability for user specified settings that govern the scheduling process (e.g., average speed; dwell times; load times; etc.).
• system shall be capable of evaluating base runs in order to optimize run in terms of least distance and travel time, based on network factors.
• Vendors should specify the range of parameters that can be user set and how the vendor will assist the transit system in the initial setting of these parameters to ensure maximum scheduling efficiency in daily operations.
- Scheduling types
• System shall have capability to perform fully automated scheduling, either in batch mode or in the scheduling of individual trips.
• System should be fully capable of automatically scheduling all trips without manual intervention unless there are insufficient drivers/vehicles.
- Subscription trips
• System shall permit the establishment of locking passengers into dedicated runs for recurring run order, meaning passenger a should be able to be permanently assigned to run 101 Monday to Friday.
- Unscheduled trips
• System shall permit trips to be placed in the system schedule but remain unassigned to a specific run; this can be accomplished through a user setting the trip to “unassigned” or “will-call” or similar means.
• System shall be capable of permitting manual insertion of such trips into the schedule, with automatic updating of the remaining scheduled pick-ups and drop-offs on the run.
- Display
• Once generated, the system shall be able to display all schedules for all runs on a given day via pdf or other digital method; display shall contain all pertinent run data, contain necessary menu, and edit tools to provide manual adjustments, as necessary, to the scheduled runs.
- Validation/violations
• System shall have internal validation controls to ensure that schedules do not violate schedule and work rules.
Additionally, system shall have the capacity to evaluate overall travel time for individual passengers to ensure that system travel time limitations are not exceeded.
• System shall be capable of generating or identifying trips that violate system parameters so that staff can attempt to remedy the violation.
- Labor rules
• System shall be capable of scheduling trips to established runs considering system labor rules including, but not limited to, operating hours, breaks, and employee work hours.
- Vehicle assignment
• In assigning passengers to vehicles and/or vehicles to system runs, system shall be capable of recognizing the need for accessible vehicles, vehicle capacity, etc., in making said assignments; system shall be able to assign vehicles to zones or other geographic locations/boundaries.
- editing schedules
• System shall be capable of adding trips to a previously generated schedule or re-assigning trips from one run to another in dynamic fashion.
• System shall be capable of evaluating individual trip parameters and select runs that best satisfy the requirements of the reservation while maintaining the integrity of existing reservations on the same run. if system generates a range of alternatives, system shall present alternatives in rank order with the highest ranked alternative indicating the “best” selection; the best selection will be chosen based on vehicle GPS of current vehicles on the road (in the case of same day trips) and the information of other trips currently within the schedule for the time that the trip in question is being booked.
• The system shall permit the system administrator to set and modify scheduling parameters to optimize service performance and service quality – factors such as time-on-board, productivity (boarding per revenue-hour, grouping trips), travel time, service costs, costs per passengers served, time between trip request and vehicle arrival, time between requested drop-off and actual drop-off, and colocation of riders at virtual stops.
- Dynamic update of all schedules
• Anytime a schedule is edited, the system must be capable of updating the schedules of all other impacted trips so all previously scheduled trips must remain on time, not violate travel time rules, etc.
- Unscheduled trips
• If the system cannot schedule all orders for the day of travel being scheduled, then the system shall be capable of displaying all such trips in its own dataset so that staff may consider manual overrides to the schedule and/or assignment of the trip.
- MDT / tablet display of schedules
• As trips are assigned to a scheduled run, the system shall be capable of graphically displaying, on the screen, the sequence of pick-ups, drop-offs, and route path for the run; this capability should be visible on both the dispatcher side and the driver side.
7. Dispatch
- Access to dispatch information
• System shall allow dispatchers access to run itineraries based on run number, vehicle number, or client name.
• System shall be capable of displaying the run number, number of passengers on the run, scheduled arrival time, estimated time of arrival and any special accommodations/circumstances.
- Vehicle assignment
• The system shall be capable of assigning vehicles to scheduled runs considering the mobility needs of customers assigned to the run, thereby always ensuring sufficient wheelchair capacity.
• Dynamic updating of assigned vehicles must be possible in order to consider vehicles pulled from service due to mechanical failure, lift failure, or other failure event found during the driver’s pre-trip inspection.
- Cancellations/no-shows
• System shall be capable of allowing dispatchers to process late cancellations (cancellations received after system policy time) and no-shows; system must be able to enforce clients are called/text/notified before no-show is approved; this data should also be easily exported into a report for enforcement of the no show suspension policy.
Same day reservation changes/add-ons
• System shall be capable of automatically displaying to the dispatcher/scheduler cancellations, same day reservations, and will-call return trips waiting for vehicle assignment (e.g., trips/reservations made but not yet assigned/scheduled).
Removal of vehicles from service
• If the dispatcher is advised that a vehicle is not fit for service, the system shall be capable of programming a vehicle substitution on the affected run(s).
View of vehicles/runs
• Dispatchers are to have a screen where they can visually locate each vehicle on a map, with the ability to filter or drill down to subset of vehicles, as necessary.
Dispatch reports
• Dispatchers must have real-time and historical reports available to view ‘violations’ in advance of them occurring, as well as runs that are running late, or likely to run late; this will enable dispatchers to proactively improve service.
Reconciliation/ trip edit function
• In the event of a system outage, the system must allow staff to update/edit past trips with appropriate arrival/departure times, odometer readings, etc.
8. Reporting
- Standard reports
• Software shall be capable of generating a range of management and service reports necessary to permit sufficient oversight of the paratransit and related services; software will also provide reports that meet national transit database (NTD), FTA, FDOT, contractual, and state requirements (transportation disadvantaged, or td); the software system shall support real-time operational supervision and on-time performance reporting – this will be accomplished via a dashboard or related technology.
• System shall also have the ability to run a certain report or reports on a set schedule and delivered to email addresses in a particular format, i.e., monthly reports on revenue and dead head hours and miles sent to an email address of the users in an excel or similar Microsoft or open-source file format.
• Examples of contractual reports that will be used or developed as part of this proposal are:
1. late trips
2. rides per hour
3. missed trips
4. service hour
5. service hours by funding source
6. revenue service miles
7. deadhead
8. OTP
9. productivity
10. ridership by funding source
- Ad-hoc reports
• System shall permit the user to create, format, and print user-defined reports based on data elements in the database.
• SQL or other scripting languages are to be available to run reports.
9. Mobile data terminals (MDTS)
- Hardware:
• Durable industry standard tablet-based hardware solution requiring no hard wiring within the vehicle.
• Ability to integrate with onboard diagnostics to automatically collect odometer readings.
• Ability to utilize 5g network coverage at a minimum provided by agency.
• System shall not require proprietary hardware.
• MDTS must provide the driver with his or her manifest and turn-by-turn navigation using modern navigation always up to date maps with access to live traffic.
• MDT’S must provide the driver with the ability to document in the manifest his or her actions as it relates to arriving and picking up the passenger, departing from the origin, arriving at the destination address, and dropping off the passenger.
• The MDT will provide the “breadcrumbs” of the driver’s location to the dispatcher.
• The MDT will provide the current trips in the manifest to the driver and the next two hours in case of cellular connectivity issues.
• If notes are entered in passenger’s trip data, driver should be able to view this information without having to press additional keys; this will avoid trip notes not being read by drivers.
• System must be able to store arrive and perform data on the tablet should cellular connectivity be lost.
• System should not allow odometer readings to be entered less than the previous day, or more than a reasonable amount more than the previous day; this is to ensure accurate odometer readings are entered.
• Users will board the vehicle and the operator will use an MDT to confirm the user trip via an assigned unique code generated by the system (or alternative method proposed by the vendor that validly links a user to their trip request on the in-vehicle operator tablet), operator will acknowledge the valid trip on the tablet and allow the user to board or redirect the user to another vehicle if the trip code does not match.
- Contract Period/Term: 1 year
- Pre-Proposal Meeting (Non-Mandatory) Date: March 11, 2025
- Questions/Inquires Deadline: March 14, 2025