VT23-005 Scheduling Dispatch Software RFP.pdf

VALLEY TRANSIT

REQUEST FOR PROPOSALS (RFP) FOR

SCHEDULING & DISPATCH SOFTWARE

RFP VT23-005

December 18, 2023

801 S. Whitman Ave

Appleton, Wisconsin 54914

Valley Transit Request for Proposals

Valley Transit Page i

TABLE OF CONTENTS

PART A – NOTICE TO VENDORS

PART B - GENERAL INFORMATION

Definitions Background Project Introduction Service Descriptions Current ITS System Disadvantaged Business Enterprise Contract & Term Funding Insurance

PART C – SCOPE OF WORK

Introduction General Software Requirements Data Interface/API Mapping Function GIS and Geocoding Function Client Database Dispatching Trip Reservations Scheduling Reporting Hardware - General Mobile Data Terminal (MDT) MDT: GPS/AVL Status Updates to Dispatch Interface MDT Communication Functionality Data Management Billing Support Data Security Data Ownership & Protection Warranty

PART D – PROJECT IMPLEMENTATION

Project Management Kick-Off Meeting System Requirements Applications Deployment System Testing & Acceptance Training Maintenance

Valley Transit Page ii

PART E – OPTIONAL SERVICES & FEATURES

Trip Reservations via Web Portal Rider App and Mobile Payment System Extended Warranty

PART F – PROPOSAL REQUIREMENTS AND SUBMITTAL INSTRUCTION

General Information Proposed Schedule Written Questions & Addenda Proposal Selection Evaluation Criteria Interview/Demonstration Protest Procedure Mandatory Proposal Requirements Written Proposal Response Cost Proposal Form Lobbying Certification

APPENDIX 1 – FEDERAL CONTRACT CLAUSES

APPENDIX 2 – CITY OF APPLETON INSURANCE REQUIREMENTS

APPENDIX 3 – GENERAL REQUIREMENTS

Valley Transit Page 3

PART A – NOTICE TO VENDORS

1. NOTICE IS HEREBY GIVEN that sealed proposals will be received at Valley Transit, 801 S. Whitman Ave., Appleton, WI 54914 for: ”PROPOSAL FOR SCHEDULING & DISPATCH

SOFTWARE RFP VT23-005” FOR VALLEY TRANSIT, DUE NO LATER THAN 10:00 AM,

FRIDAY, JANUARY 26,2024.

2. It is the proposer's sole responsibility to insure that the proposal is timely and physically received by Valley Transit prior to the deadline set forth in this notice.

Receipt of a bid/proposal by the mail system or other City departments does not constitute receipt of a bid/proposal by Valley Transit.

3. All proposals must be submitted in an envelope sealed by the bidder or designated representative. All proposals should be addressed to the General Manager, c/o Valley Transit, 801 S. Whitman Ave., Appleton, WI 54914. On the outside of the envelope, the bidder should distinctly indicate the name and address of the bidder and in the lower left corner should clearly indicate the envelope contains a sealed proposals for:

“PROPOSAL FOR SCHEDULING & DISPATCH SOFTWARE RFP VT23-005.” Any proposals not complying with these instructions will not be considered submitted to Valley Transit, and shall be returned to the proposer unopened and unread.

4. Submission of proposal documents by facsimile equipment or electronic mail (email) will not be accepted.

5. This notice establishes a time by which sealed proposals must be physically received by Valley Transit. No proposals will be accepted after that deadline.

6. Valley Transit is not responsible for proposals submitted in any other way except those submitted in strict conformance with these instructions.

7. A written request for the withdrawal of a proposal or any part thereof may be granted if the request is received by the Valley Transit prior to the specified time of submission.

8. All formal proposals submitted shall be binding for sixty (60) calendar days following the submission date.

9. If applicable, proposer must comply with all necessary insurance requirements, as required of the project and as noted in the City of Appleton Insurance Requirements.

10. If the proposal is accepted, the bidder must execute and file the proper contract within ten (10) days after award and receipt of the contract form for signature.

11. Valley Transit reserves the right to reject any and all proposals and to waive any informalities in bidding.

12. For further information concerning this Request for Proposal, contact Debra Ebben, Administrative Services Manager, email: debra.ebben@appleton.org or telephone

(920) 832-2292.

Ron McDonald General Manager

PUBLISH: December 17, 2023

Valley Transit Page 4

PART B - GENERAL INFORMATION

Definitions

The following definitions are used throughout the Request for Proposal (RFP).

‘Proposer’ or ‘Vendor’ means a firm submitting a proposal in response to this RFP.

‘Provide’ means to furnish and implement.

The City of Appleton/Valley Transit is hereinafter referred to as “Valley Transit.”

Background

Valley Transit, owned and operated by the City of Appleton, provides fixed route bus and complimentary ADA demand responsive paratransit service along with other ancillary paratransit services. Valley Transit’s service area generally consists of the Cities of Appleton, Neenah, Menasha and Kaukauna; Towns of Buchanan and Grand Chute; and Villages of Fox Crossing, Kimberly and Little Chute.

Valley Transit’s paratransit services are provided through a contract with a private provider. The current contractor utilizes a fleet of 32 vans. The programs provide approximately 480 demand response rides per weekday, 120 rides on Saturday and 25 rides on Sunday to seniors, individuals with disabilities and workers. Paratransit trips consists of regularly scheduled trips and will-calls.

Further info about Valley Transit can be found at: myvalleytransit.com

Project Introduction

Valley Transit is seeking competitive proposals from interested, qualified and experienced Contractors to provide dispatch and scheduling software solution to manage its ADA complementary demand responsive service and several ancillary paratransit services. These transportation services are summarized within this RFP document.

The vendor shall comply with all requirements listed in this RFP.

Valley Transit’s primary goals in implementing the system include:

Manage resources efficiently and reduce costs Track multiple programs and ride funding sources by municipality and county Improve oversight of services and performance monitoring Maintain compliance with the Americans with Disabilities Act (ADA)

Valley Transit is currently rebidding the contract for a paratransit service provider. The awarded contract for service begins on July 1, 2024. It is Valley Transit’s intent to implement the next scheduling & dispatch software system in conjunction with the next service provider.

Valley Transit Page 5

Service Descriptions

The awarded vendor’s solution will need to manage trips provided under the six services described below.

ADA Complementary Paratransit (Valley Transit II): The service is a demand-responsive, limited advance reservation complementary paratransit service for persons whose disabilities prevent their use of the fixed route transit services offered by Valley Transit. This service is designed to comply with the ADA. This service is hereinafter referred to as ‘VTII.’

Senior Transportation Service: An ancillary paratransit service that provides rides to elderly individuals age 60 and over residing in the Fox Cities portion of Outagamie County and the Appleton portion of Calumet County.

The Connector: An ancillary paratransit service designed to provide rides for customers traveling to and from work outside the fixed route area (ESA: Extended Service Area) or outside the fixed route service hours (ESH: Extended Service Hours). The service is an advance reservation, demand-responsive, common-carrier transportation service that provides rides to, from, and within two service area zones. The purpose of “The Connector” is to: provide transportation options to the less densely populated areas of Valley Transit’s service area; offer a late and early morning option for second and third shift workers; and provide a first-mile, last-mile connection to Valley Transit’s fixed route transit system.

Outagamie County Human Services Transportation (OCHST): An ancillary paratransit service which provides limited advance reservation, demand-response, common-carrier transportation service to, from, and within two defined service area zones, and all of Outagamie County. The purpose of the Outagamie County Human Services Transportation program (hereinafter referred to as “OCHST”) is to provide transportation options for individuals who for other reasons are unable to use the fixed route or shared ride services. The is a demand response service for qualifying riders whose trip origin and/or destination is within Outagamie County.

Northern Winnebago Dial A Ride (NWDAR): This transportation service is demand response for ambulatory riders age 60 and over. The level service is “origin to destination service”. Qualifying riders reside within City of Neenah, City of Menasha, Town of Menasha, the Village of Fox Crossing, or within the “Heritage Area”.

Outagamie County Rural (OC Rural): This transportation service is a demand response, origin to destination service designed for Outagamie County residents who are elderly or have a disability to travel into and out of the Valley Transit ADA service area from the rural portions of the County.

Other service characteristics are described in the current service brochure found at:

https://myvalleytransit.com/demand-response-programs/

Valley Transit Page 6

Current ITS System

The current software system used to manage paratransit clients and trips is Ecolane. The software is web based with mobile data terminals (tablets) in the vans. These tablets give schedules as well as route maps, GPS location and speed tracking. The current system was implemented in 2019 and the current contract is expiring.

To summarize roles, Valley Transit staff mange the customer registration and program eligibility tasks within the current software. Valley Transit also uses the product to oversee the system through various screens and reports. Valley Transit also uses a number of specified data exports needed to import into our main data system (currently TransTrack) for federal reporting and other system wide reports. The next system would need to have the capability to export data via API. See Data Interface/API Section below.

The contracted transportation provider performs trip reservation, dispatching and scheduling tasks within the system.

Disadvantaged Business Enterprise

Valley Transit has established a Disadvantaged Business Enterprise (DBE) program in accordance with regulations of the U.S. Department of Transportation (DOT), 49 CFR Part 26. It is the policy of Valley Transit to ensure that DBEs, as defined in 49 CFR Part 26, have an equal opportunity to receive and participate in DOT-assisted contracts.

There is no contract goal established for this agreement. If a proposer is certified with the State of Wisconsin as a DBE vendor, please indicate DBE certification within the submitted proposal.

Contract & Term

Valley Transit will enter into a fixed price contract with the selected vendor. The resulting contract will include this RFP document and the contractor’s proposal as component parts. The service agreement term will be for five (5) years with options to extend for three (3) one-year periods. This contract shall automatically extend into each one-year option period unless either party notifies the other, in writing, 90 calendar days prior to expiration of the initial and/or succeeding contract option period(s). A sample contract is provided in Appendix 4.

Communications in connection with this contract shall be in writing and shall be delivered personally or by email; or by regular, registered, or certified mail addressed to the officer(s) or employee(s) of Valley Transit and of the Contractor designated to receive such communications.

Telephone calls may be used to expedite communications but shall not be official communication unless confirmed in writing.

Valley Transit is exempt from the payment of Federal, State, and local taxes. Taxes must not be included in proposal prices. Valley Transit will furnish necessary exemption certificates upon request.

Valley Transit Page 7

Funding

The successful Contractor shall be responsible for complying with all applicable laws and regulations governing the services described in this RFP as a contractor of Valley Transit.

Funding for this project may include Federal, State of Wisconsin, and local funding. Specific Federal requirements are outlined in Appendix 1.

Insurance

The Contractor shall not commence work until it has obtained all insurance required. See Appendix 2.

Valley Transit Page 8

PART C – SCOPE OF WORK

Introduction

The selected firm’s ITS solution must provide Valley Transit with a turn-key product that will, at a minimum, provide the elements and functions described in this RFP. Any functionality above and beyond the system described in this RFP should be priced out as separate modules in the Cost Proposal Form.

The selected firm will be the prime contractor for the project and, as such, will be responsible for managing the entire scope of services as described in this RFP and other documents tied to this process.

The specifications herein may not have addressed all functional elements of a particular vendor’s software product/ITS technology. Such omissions are not intended to mean that Valley Transit does not desire to have that functional element as part of the software or technology system(s) to be purchased under this procurement.

Valley Transit recognizes the rapidly changing pace of innovation in mobile communications and technology. Any specification in this RFP that may hinder or limit the vendor’s proposed deployment approach should be noted in writing through the ‘written question’ submittal step of this procurement. The written question should contain a statement explaining how the proposed alternative would better serve the needs of Valley Transit. Valley Transit will consider each request and share responses through the addenda process.

General Software Requirements

Valley Transit requires a software solution that is 100% cloud-based with web-portal access provided anytime of the day (24 hours a day, 7 days a week, 365 days a year). Solution must be fully functional via Chrome. If another browser is essential to system operation, offeror must indicate required browser to be used.

Administrative and Dispatcher user interface shall be simple, intuitive, and easy to use.

Administrator shall have the ability to create new accounts for instant login. Software will provide at least three (3) account privileges (dispatcher/scheduler, viewer, administrator, etc.).

A minimum of twenty-five (25) staff would require access to the system. System will support concurrent logins with no degradation of performance.

Vendor shall back-up and protect, for a minimum of sixty (60) days, any software configuration settings, any Valley Transit provided data that has been modified for use by the software and any new data produced by the software itself.

At the time of implementation, vendor’s software must be the current version and compatible with the specified hardware. Valley Transit desires a solution that requires no installation of any kind on Valley Transit’s computers or servers with everything stored on vendor’s servers/cloud.

Valley Transit Page 9

Vendor must always ensure that Valley Transit is utilizing the latest approved and beta tested software version available.

Valley Transit requires a proven solution. Vendors must have successfully installed/implemented proposed full system at a minimum of five (5) public transit system properties in the United States.

Cost proposal format will include software support/hosting agreement for contract year-one and an annual breakdown of costs for the remaining 4 years of the initial contract and additional three (3) 1-year renewal options.

The vendor’s solution shall also provide the minimum capabilities described below.

Data Interface/API

The awarded vendor is required to partner with Valley Transit and other authorized vendor products to interface and share data produced by the vendor’s product, when applicable. All products will evolve over time, so it is also important for Valley Transit to establish partnerships with vendors that are willing to work with each other, adapt to change and build upon current connections to improve the flow and accuracy of data.

Valley Transit employs a cloud-based data management and reporting system provided by TransTrack. This product imports data from many silos within our transit system, including paratransit service data. The awarded vendor will be required to work with TransTrack and supply a data connection (API or SQL) at no additional cost to Valley Transit. The paratransit data needed includes run productivity and trip data. This data is used in TransTrack for analytics and reporting related to program specific ridership, on-time performance and various service data required for National Transit Database reporting. See a summary of some fields currently exported from the existing product. The expectation is that the awarded vendor will have a proven data connection developed prior to contract award.

Run Productivity includes:

Run; Driver Name; Trips (completed & no show); actual total service time & distance; actual deadhead time & distance; and actual revenue time & distance.

Trip includes:

Customer Number; Customer Name (First, Last); Trip ID; Mobility Device; Accompanying Riders (Children, Companion, Other); Trip Date; PCA; Trip Status; Fare Type; Fare Type quantity; Fare collected; Fare Billing Code; Service/VT Program; Additional Passenger Fare; Billing Code; Trip Purpose; Trip Duration; Trip Distance; Vehicle ID; Run ID; Driver Name; requested pick-up or drop-off time; actual pick-up and arrival time; address (pick-up and drop-off); and pick-up and drop-off coordinates.

Valley Transit Page 10

Mapping Function

Valley Transit requires the following mapping capabilities/features shall be provided:

Utilize GPS to provide automatic vehicle location (AVL) in conjunction with mapping that allows users/dispatchers to identify current vehicle locations, based on the last known point in the schedule. Vehicle location information will be automatically refreshed at least every 30 seconds or more frequently according to event or rule GPS reporting.

Map display shall clearly identify the service area boundary of each program. Graphic or query functionality must be present to determine if client’s address or requested trip origins and destinations are within the program specific service area.

Access to AVL maps must be seamless from within the scheduling software (e.g., user should be able to generate map with single mouse click or menu selection).

Base maps must contain current attributes on street segments, addressing, speed limits, etc. Vendor shall be responsible for supplying a fully up-to-date map complete with all attributes necessary for point-to-point scheduling using coordinate geography (not zones). Street network shall permit definition of segment characteristics, such as speed limits, one-way direction, etc.

System shall provide methods of allowing user editing of the base map to add new streets, change municipal boundaries, define incomplete address ranges, etc.

Contractor shall provide map editing support throughout agreement.

GIS functionality shall include ability to develop overlays or coverages of municipal boundaries and other key geographies. Map shall include the entire Valley Transit service area. Map shall have the ability to expand into additional communities if service expands.

GIS functionality shall include ability to define service-based zones, such as fare zones, etc. This is a critical functionality that must be provided.

System shall permit definition and display of physical features that act as barriers to transportation.

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. Include ability to limit display of this information according to permissions or map version.

Map display shall clearly display vehicle icon and location. Vehicle icon shall include operator ID, vehicle ID and speed.

Map display features shall include zoom in or out, pan in any direction and point-and-click on features and vehicles to retrieve information. The map should be expandable to full screen view.

AVL location data will begin when the ignition is turned on and continue reporting until the ignition is turned off. Location of vehicles with no assigned pick-ups will also be tracked and visible in mapping.

Map will display last known position on any unit suffering loss of GPS signal, and shall visually display and provide an alert to show a vehicle that is not in communication. Map will clearly mark each vehicle when more than one travels on the same street segment.

Provide historical playback of vehicle locations with speed data

Valley Transit Page 11

GIS and Geocoding Function

Valley Transit requires that the vendor’s software product provides GIS functionality. The following capabilities/features shall be provided:

System shall be capable of exporting data and graphic images to other software platforms. If the software is limited to basic mapping functions, then data shall be exportable to standard GIS software (e.g., ESRI mapping products) enabling external GIS analyses.

Service area map shall contain definitions of street segment name and address ranges.

System shall have full geocoding capability allowing Valley Transit 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.

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.

System should have the capability to manually pin multiple doors at the same location to direct driver to exact pick up spot.

System shall have the capability to calculate drive length and duration during the scheduling process.

For any trip reservation, system shall be capable of providing, using the GIS capabilities of the software, a map image of the trip origin and/or destination.

The system must be able to calculate, autofill and report the municipality and county of each trip’s home address, trip origin and/or destination. If needed, Valley transit will provide municipal and county shapefiles covering the entire service area.

Client Database

The Client Database shall provide the following capabilities/features:

The client database shall be capable of providing a full range of data elements for each client in the system. Information shall include full identification including gender, address, municipality, county, contact details, third party/emergency contacts, disability status, mobility aides used, required accommodations, caregiver, language spoken by client, program affiliation, and third-party contract payee options Additionally, system shall permit assignment of various demographic codes, such as elderly, youth, etc.

System shall be capable of tracking trip purpose for each trip with user customization possible in terms of defining various trip purposes.

The 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, identification number or similar characteristic. When looking up a customer, auto-complete features are desirable to minimize user input.

System shall be capable of registering new clients, capturing information about addresses, disability type, space requirement, load/unload time, fares, payment

Valley Transit Page 12 options, eligibility conditions, funding sources, etc. while a customer service agent has the new customer on the telephone.

System shall permit edit of all fields in a customer’s records in a real-time basis and shall permit suspensions (temporary) of service.

System shall be capable of recording and displaying trip history details specific to each client, such as recent trip dates, trip origins or trip destinations.

System must have the ability to capture information on trip cancellations and no-shows specific to individual customers.

System calculation and entry of trip origin and destination municipality and county is critical for Valley Transit in order to properly invoice local share accurately. Municipality must be its own unique field separate from home address because mailing address can sometimes list a different municipality.

The selected proposer, as soon as practical after notice to proceed from Valley Transit shall be responsible for providing a data “template” in order for staff to begin compilation of information necessary to complete the client database elements required for use in scheduling, trip assignment, and reporting. The selected proposer will evaluate current client database and develop appropriate data conversion process that converts existing client information into a compatible format for use in the proposed scheduling and dispatching software solution.

Dispatching

The system’s dispatching tools must include the capabilities/features listed below.

Communication between dispatching and reservation/scheduling functions Dispatching effectiveness and performance evaluation reports Graphic display of individual routes with easily identifiable pick-ups, drop-offs, and breaks Ability to identify and assign open returns (will call trips) Ability to identify and adjust service for no-shows, cancellations, and service interruptions Ability to identify scheduled and actual arrival times Monitor service in real time

Access to Dispatch Information

Systems 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 circumstances.

Information displays must associate with the time of day (e.g., 10:00 a.m. events are displayed at the top of the list window when the dispatcher makes queries at 10:00 a.m.).

Valley Transit Page 13

Driver Assignment

System shall be capable of assigning drivers to runs. System shall take into account driver work schedules and other factors to ensure compliance with system policies.

Vehicle Assignment

System shall be capable of assigning vehicles to scheduled runs taking into account mobility needs of customers assigned to the run, thereby ensuring sufficient wheelchair capacity at all times.

Dynamic updating of assigned vehicles must be possible in order to take into account 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. 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, system shall be capable of programming a vehicle substitution on the affected run(s).

Trip Reservations

The system’s trip reservation tools shall include the following capabilities/features:

Real Time Trip Details Entry

System shall permit trip booking while transit personnel are on the phone with the client/customer. System must be capable of processing both subscription (standing order) and demand response trips in this manner. System shall be capable of processing same day trip orders.

System shall permit reservation staff to access client records by entering client last name, telephone number, or other ID number. Typical protocols involve booking trips using client last name. Additional details must be available to the customer service agent in order to distinguish between customers with the same last name. System will have the capability to

Valley Transit Page 14 automatically populate the reservation screen with the customer data, including commonly used locations, mobility device, eligibility, PCA, etc. after the individual has been identified.

Pop-up windows or list boxes shall be used to display lists of clients for easy access and selection. Once selected, pertinent data from the client database file shall be accessible to the reservation clerk, either through on-screen display or pop-up window.

Default and Common Pick-Up Address

System shall default to the client’s home address as the pick-up location. System shall provide ability to enter alternative addresses through key stroke entry or through use of list boxes 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 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 destination from these fields and populate trip destination fields through this selection process.

Trip Reversals

System shall be capable of automatically generating trip reversals or booking 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 take into account 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.

Advance Reservations

System shall be capable of accepting trip reservations for a period of at least up to 365 days in advance of the requested trip date.

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

Valley Transit Page 15 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 service representative to easily and quickly access existing trip reservations for the client in order to edit travel destination, trip dates, and/or travel times.

System shall permit cancellation of any trip in the system in advance consistent with defined system policies on trip cancellations. 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 capable of temporarily suspending a client’s eligibility for service. 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, system shall not permit trip booking. 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.

Personal Care Attendants, Companions, and Escorts

System shall be capable, during the course of the reservation entry process, of allowing customer service agents to add personal care attendants and companions to the trip order.

Fare Computation

System, at the conclusion of trip booking, shall provide a confirmation of the booking with fare(s), if applicable, to be paid by the user(s), escorts, or companion.

Trip Cancellation

System shall provide methods to enable customer service agents to easily retrieve an existing trip reservation and, upon customer request, cancel the reservation. System shall provide various trip codes to document the reason for the cancellation (e.g., “cancelled on customer request” etc.).

Scheduling

The system’s scheduling tool shall have the following capabilities:

System shall have capability to perform fully automated scheduling, either in batch mode or in the scheduling of individual trips. The system shall provide dispatchers with web-based tools to proactively manage OTP, no-shows, cancellations, subscriptions and late trips. The system shall automatically send updates of the dispatched trips to the Mobile Data Terminals (MDT). The

Valley Transit Page 16 web-based tools provided will allow managers/supervisors to monitor their driver’s performance in real-time. The system shall optimize same day trip orders with advance trip orders and automatically send updates to the MDTs. The scheduling process shall be completely automated and have a proven capability to function without a scheduling position initiating the scheduling. The automated scheduling process shall continuously look to improve schedules based on real time operating factors such as cancellations, no-shows, vehicles positions, driver performance, etc.

Automated Batch Scheduling

System shall be capable of scheduling, in batch mode on a next-day basis, all reservations for a designated travel day. Scheduling shall be based on the actual street network in the service area (e.g., actual x- and y- coordinates, not zones), parameters associated with network segments as established in the GIS system, physical barriers, speed parameters, time of day, and appropriate dwell times for the boarding and alighting of passengers.

Subscription Trips

System shall permit the establishment of base runs or subscription templates based on existing standing orders. 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.

Avoiding Capacity Constraints

System should be able to prioritize ADA Paratransit trips over other complimentary services and put a limit on the percentage of trips that are subscription trips when scheduling rides close to capacity.

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 manual setting of the trip to “unassigned” or “will-call” category or similar means.

System shall be capable of permitting manual insertion of such trips into the schedule, with automatic dynamic updating of the remaining scheduled pick- ups and drop-offs on the run.

Same Day Trip Orders

System shall be capable of taking trip orders on a same day basis and dynamically scheduling the trip into existing schedules. System shall consider existing path of route travel, existing customer assigned trips, and system policies on travel and pick up time windows in making the scheduling assignment. If system is capable of producing multiple solutions to the trip assignment, priorities, expressed on some type of score or other method, it shall show the best possible choice of assignment.

Valley Transit Page 17

When a same day order is accepted and assigned to a run (or unassigned run is assigned to a run), it is imperative that the system shall be capable of dynamically updating the remaining scheduled pick-ups and drop-offs on the run’s schedule.

Service Zones

System shall be capable of producing schedules, by run, in chronological order or by sequential run number, indicating projected arrival time of system vehicles at each origin and destination.

Schedules must be developed on zones or counties, based on user specified service zones.

System must be capable of recognizing geographic zones and assign trips to the proper zone when systems serve multiple counties with dedicated vehicles and staff.

Display

Once generated, system shall be able to display all schedules for all runs on a given day. Display shall contain all pertinent run data and 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 capacity to evaluate overall travel time for individual passengers to ensure that system travel time limitations are not exceeded.

Each service has its own service area and limitations based on the trip. System shall be capable of determining if the trip meets the criteria for the specified service zone and time frames before booking. System shall be capable of generating or identifying trips that violate system parameters so that staff can attempt to remedy the violation.

Manual Override

System shall provide the capability of scheduling staff to manually move trips after schedule development. When such overrides are made, the system shall record and time-stamp the override action in the trip record (or in an associated database) in order to provide a historical account of changes to the original (booked) reservation.

Labor Rules

System shall be capable of scheduling trips to established runs taking into account system labor rules on work 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 have the capability of assigning vehicles to zones or counties.

Valley Transit Page 18

Editing Schedules

System shall be capable of adding trips to a previously generated schedules 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.

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. The scheduling process must be completely automated and have the capability to function without a scheduling position initiating the scheduled. The automated scheduling process must continuously be looking to improve schedules based on real time operating factors such as cancellations, no-shows, vehicles positions or driver performance. The system must optimize same day trip orders with advance trip orders and automatically send updates to the MDTs.

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.

GIS Display of Schedules

Once trips are assigned to a scheduled run, the system shall be capable of graphically displaying, on the GIS system, the sequence of pick-ups, drop-offs, and route path for the run.

System Parameters

System shall have capability for user specified settings that govern the scheduling process (e.g., average speed; dwell times; load times; etc.).

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.

Reporting

Software shall be capable of generating a range of management and service reports necessary to permit sufficient oversight of the paratransit service and clients. Software will also provide

Valley Transit Page 19 monthly, quarterly and annual reports that meet National Transit Database (NTD), ADA service oversight and state requirements. Required data by paratransit program includes ridership, revenue miles, dead miles, revenue hours, dead hours, missed trips, no-shows, late cancellations, trip denials, trip length (excessive trip lengths) and on-time performance.

Additional reporting would be required for each program, including attributes by municipality, fare type and county of origin.

Software shall be capable of reporting municipality and county of each trip origin and destination. Municipality must be a unique field that is calculated based on mapping, not mailing address. The municipality used in mailing address can differ from actual municipality.

The software system shall support real-time web-based operational supervision and on time performance reporting. All reports are to be completely web based, can be run on demand and exportable into csv, pdf, word, etc.

System shall also have the ability to run a certain report or reports on a set schedule and delivered to an email address in a particular format, i.e. monthly reports on revenue and dead head hours and miles sent to an email address of the user’s in an excel file.

Ad-Hoc Reports

System shall be capable of permitting the user to create, format, and print user- defined reports based on any data element contained in the database.

Hardware - General

Valley Transit is seeking to implement tracking and driver interface hardware in thirty-two (32) revenue vehicles used in demand-response service. All vehicles are owned and operated by a contracted provider. The proposed system should also allow for the integration of new vehicles into the system.

Valley Transit currently owns the tablets, mounting equipment and data plan. Current tablets are Samsung Galaxy Tab A7 Lite 32 GB with a Verizon data plan.. Valley Transit’s preference is to continue using this equipment with the next system. Valley Transit will consider solutions that require new MDTs/tablets, data plan and/or vehicle mounting hardware. If these items are necessary, please explain with detail in written response, as well as include an itemized cost breakdown for items proposed.

Mobile Data Terminal (MDT)

The MDT unit and driver application shall have the following features/functionalities.

Automatic display of driver login screen when vehicle/MDT is powered up Track driver behavior, including driving speeds Device locking mechanism while vehicle in motion Automatic Vehicle Location (AVL)

Valley Transit Page 20

GPS location, including speed and direction Real-time and historical vehicle tracking Real-time messaging between dispatch and drivers Driver login using employee identification number. MDT will validate info with software.

Should the driver turn off the ignition during the course of her/his shift for less than thirty

(30) minutes, she/he should not need to logon again as the current data will be retained.

Display will provide current system time, the time should be able to be depicted by a twenty-four (24) hour clock, or alternatively an AM/PM designation; communication network status; and will also provide ability to adjust volume and backlighting to suit individual operator preference.

Capable of providing navigation aid to operators by displaying in-vehicle map of next destination. This process shall be hands-free, and operators should not have to enter destination address to use map navigation, as the software will do this automatically and adjust according to geo-location. Usage of the navigation aid with manually entered points, including intersections, shall also be supported. The navigation aid shall be map-based with the vehicle always centered on the display, shall continuously and accurately depict the vehicle’s current location on a map that provides street names and landmarks, and shall re-compute a route recommendation if the operator deviates from the initial recommendation. The navigation aid shall provide user-activated options for both audible and visual directions.

Navigation functionality will be integrated into the in-vehicle software application and will not be a separate application.

Interface with the scheduling and dispatching system to access manifests, download them to the vehicle, manage manifests on the vehicle, and capture and send data back to the system for record keeping and reporting. Time and odometer reading for each trip event should be captured.

The exchange of data between the vehicles and scheduling and dispatching system cannot require any form of manual intervention.

The entire manifest should be stored on the MDT in case of communication interruption, but manifest updates must be possible in real-time or near real-time (within one minute).

Audible alerts for certain updates, messages or manifest changes should be possible.

GPS-based vehicle location should be reported to the scheduling and dispatching system at least every 30 seconds, and with every data and communications request sent from the MDT. The system must have the capability of displaying this data on the system’s map display, along with other relevant data such as speed, door status, and idling.

Vehicle operators should be able to quickly enter status updates to the manifest as they progress through their assigned run.

The Proposer should describe features that would permit or forbid the operator from changing the order of trips on the manifest.

A means shall be provided to allow the vehicle operator to cancel and correct an incorrect trip status message or data entry.

A means shall be provided to ensure that all manifest updates and changes acquired from the system are received by the MDT and that the system receives all trip status

Valley Transit Page 21 messages sent from the MDT.

Fallback mode of operation that preserves normal functions to the greatest extent possible whenever the data channel or system is unavailable. The objective is to keep the vehicles operating for extended periods of time regardless of the status of data communications and with minimum need to consult hard copies of the manifests. While in fallback mode, all functions must operate normally, with the exception that manifest additions and deletions will not occur. All data communications messages, trip status messages, and GPS location messages shall be queued for later transmission. The system must be capable of buffering queued data messages for at least a full-service day.

A zone calculation for each trip to support National Transit Database reporting purposes should be an option. The zones will capture urbanized vs. non-urbanized areas.

The MDT unit will have an option that will allow Automatic Vehicle Location information to be passed to the server and stored in the database based on automatic refresh rates every 30 seconds or more frequently.

MDT: GPS/AVL Status Updates to Dispatch Interface

In addition to the in-vehicle functionalities described above, the proposer’s technology solution shall provide the following functionality to system dispatch operations:

Event Based Reporting

When a function is performed, the location of the vehicle shall be reported along with any data relevant to the performance of the particular function.

Distance Traveled Reporting

Every time the vehicle has moved a predetermined distance the MDT shall automatically report the vehicle’s location to the host system in order to avoid unnecessary reports from vehicles that have not moved from their previously reported positions.

Time Elapsed Reporting

Vendor shall indicate the frequency of coordinate reporting, based, in part, upon the transmission capacity of the communications infrastructure, costs, etc. If a report is not received at the specified interval then the host system shall be alerted to the fact that for one reason or another that vehicle is out of coverage.

Hybrid GPS Reporting

System may incorporate the advantages of all three of the preceding methods. The requirement of GPS is to receive information ONLY WHEN desired and not waste airtime sending GPS information that is not useful to the dispatch operations.

Valley Transit Page 22

Poll-on-Demand

MDT shall be capable of reporting GPS based on a polling request message from the Host-end Application Software at the dispatch location.

The Proposer should describe standard status updates supported as well as what types of customized updates are possible or customizable by the user.

Driver Application Communication Functionality

The Driver Application displayed on the MDT shall have, at a minimum, the following communication functionalities:

Visual/Audio Alerts

MDT shall be capable of providing visual and audible alerts to indicate incoming messages.

The MDT unit shall be capable of sending a message and notifying the driver of the success or failure of the transaction.

Operator Response

The driver must be able to acknowledge incoming messages (as deemed necessary). After the driver acknowledges an incoming message, it shall be displayed on the MDT unit.

The MDT unit shall also be capable of allowing the driver to respond to a message. This acknowledgement shall be through use of the units’ function keys. The MDT unit shall be capable of sending a message and notifying the driver of the success or failure of the transaction. The option will be given to the driver to resend the message should the message not be delivered successfully.

The MDT unit shall restrict access to all functions while the vehicle is in motion. GPS telemetry, current system time, communication network status, and new message indicator may be…