Attachment K - On-Demand Solution Specifications.xlsx
XLSX spreadsheet 23 KB Posted
- Attached to
- Transit Service Project
- Solicitation number
- 65-RFP050124AMW
- Issued by
- Orange County, Chapel Hill Town, North Carolina
About this file
This document is an attachment for a state and local contract opportunity issued by the University of North Carolina at Chapel Hill's Department of Transportation and Parking. The University is seeking proposals for the redevelopment of its Point-to-Point (P2P) transportation management system, focusing on three key aspects: an on-demand shuttle reservation, dispatch, and tracking solution; a fixed-route solution with support for General Transit Feed Specification (GTFS) feeds; and a ride aggregator application supporting live bus tracking of the fixed-route service. Interested vendors may submit an offer for any one or more of the requested solutions. The contract opportunity involves the jurisdictions of Orange County and the Town of Chapel Hill in North Carolina.
The attachment provides detailed technical specifications and requirements for the on-demand solution, including platform functionality, data security, user interfaces, reporting, support, and driver/rider applications. It also addresses testing, training, and implementation requirements. The contract opportunity does not provide information on pricing terms, set asides, incumbents, funding requirements or sources, or award dates.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Attachment L - Ride Aggregator Application Specifications.xlsx | XLSX spreadsheet | |
| RFP050124AMW Transit Service Project FINAL.pdf | ||
| Attachment J - Fixed-Route Solution Specifications.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| ATTACHMENT K: On-Demand Solution Specifications | |
| Platform | Describe how all safe ride services would be centralized in a single platform. Can they be scaled across multiple service zones all within the same window? |
| Platform | Describe how operation speed of the platform will be optimized. |
| Platform | Describe how algorithms will be utilized to help reduce operating costs |
| Platform | Describe the product's efficiencies and effectiveness and how it will apply to all P2P service types regardless of funding source or trip purpose |
| Platform | Describe the way that data will be securely stored in the cloud. Will data still be easily accessible? |
| Platform | Will riders be able to make reservations by app, website, and phone? |
| Platform | Describe how the product can have specific configuration. i.e. one zone with a door to door functionality and others with stop to stop configuration. |
| Platform | Describe how automatic map updates can be pushed out. |
| Platform | Will dispatchers have the ability to override any automatically brokered trips? |
| Platform | Describe how time restrictions to zonescan be attached to certain configurations. i.e. configuring a zone as door to door during certain hours, and stop to stop during other times. |
| Platform | Describe how service and zone additions shown in a window will allow you to see all existing services directly on the map |
| Platform | How will service zone boundaries be changeable from within the web application? and describe how the vendor will not require interacting with the software vendor to complete the changes of the service. Also describe how service and zone level configurations will be configurable and on the fly and self serve. |
| Platform | Address the ability for dispatchers to search any field such as ID numbers, Date of Birth, address etc. |
| Platform | Describe how the vendor will be able to provide demand forecasting based on recurring trips and certain periods of time |
| Platform | Will SAAS and SOC2 compliance be possible? |
| Platform | Describe how certain user groups should be granted the option to choose whether to utilize the third-party fleet, based on administrative discretion |
| Platform | Address whether or not the system has capability to have notes attached to any phone booking (e.g. indicating details on pick-up/drop-off location, or any other relevant information). This information should be visible to the driver during pickup. |
| Platform | Address any automation in the trip brokering based on an intelligent algorithm. This will allow for staff to dispatch multiple dedicated fleets, and also to non-dedicated fleets in cases of overage in demand. Fleet priorities may be set by the university. |
| Platform | Describe how automated brokering for each day will be handled, taking into consideration the recurring trip bookings and scheduled trips. The system needs to optimize for least distance and travel time, based on the street network segment parameters stored in the system. |
| Platform | Address how on-demand trips can be booked through the mobile app or by calling into the university call center. If it is the first time they have used the service, the scheduler needs to be able to create a profile within the same window. |
| Platform | Describe how the solution can automatically broker ridesharing or comingling functionality. Administrators will have the capibility to change the criteria around how efficient the system is, or how important short trips and passenger experience is, and define the service to fit their specific requirements around public service offerings. |
| Platform | Describe how the solution can automatically produce a driver schedule for each operator run, indicating the driver pickup and drop off. Any trips that come in during these runs need to be added to the driving schedule according to the algorithm criteria. If pooling is allowed, pooling should occur automatically. |
| Platform | Address if the solution can provide map displays with pop up windows that show: |
• Vehicle Number;
• Operator;
• Driver;
• Logon state;
• Upcoming Pick-up/Drop-off location (or a list of next events).
• Trip and passenger Information;
| Platform | How will historical trip information to be replayed by the university? |
| Platform | How will logged data be retrieved, even if it has been archived? |
| Platform | Address if it will be possible to select any time period for access to the historical data. |
| Platform | Address if the solution will be a SAAS platform with no specialized infrastructure such as servers required from the university. |
| Platform | Describe how the system can continuously optimize and move trips if required so driver manifests are updated in real time and trips may be moved between vehicles for maximum efficiency when conditions change. |
| Platform | Describe the solutions trip brokering needs. Can the system seamlessly allocate trips to a ride hailing service with varying priorities so trips are allocated in special conditions to non-dedicated vehicles? |
| Platform | Address the availability of custom fields that are avialable for rider data capture |
| Platform | Can the solution provide manual intervention to assign trips to specific duties while tracking reason for such a change? |
| Platform | Address the need for a map display that shows the following information via vehicle icon shape, colour coding, and/or overlays: |
• Network connection status;
• Fleet;
• Service state (e.g. in-service, not in service)
| Platform-Reporting | Address the availability of custom templates available for reporting purposes within the platform. Can reports also be filtered by things like service type? |
| Security | Will the SAAS platform be SOC-2 compliant? |
| Security | Will the SAAS platform be HIPAA compliant? |
| Technology | Describe how hardware equipment will be installed. If any fixed on-board equipment will be needed to be installed, it needs to be easily accessible, modular, and easily removable to facilitate maintenance and repair of the equipment. |
| Technology | Describe how any wiring will be correctly installed and managed. If any wiring and connectors are needed for the project, they need to be appropriate to on-board and other transit environments where the equipment is to be installed. The vendor’s cables are shielded where necessary to avoid interference problems. |
| Technology | Describe how wireless communication needs will be assessed? If any fixed or permanent onboard components are part of the wireless fleet location and communications equipment, the proposer will provide a wireless communications system design for client approval. |
| Technology | Describe the protection of wireless and wired equipment. The wireless equipment and systems operate properly under environmental conditions encountered on vehicles to include temperature extremes, humidity, dust, power variations, shock, vibration, and EMI/RFI interference |
| Technology | Address the need for wireless equipment and systems that updates frequently and is error free. |
| Testing | Describe how the proposer assists in checking the existing network support to determine if performance will be sufficient, and if not, assist in identifying network improvement strategies |
| Testing | Describe how the existing client database can be migrated by the contractor into the new system prior to launch |
| Testing | Describe the process of the testing of software, components, and features. This should be done with UNC's own data |
| Testing | Describe the testing timeline to ensure it is completed prior to launch date. |
| Testing | Describe the testing of overall components such as billing, reporting, scheduling, the base map, vehicle location/Tablets/wireless fleet communication functions |
| Support | Describe the technology and software support that will be available to UNC and the times at which this support is available |
| Support | Describe how Issues and Action items related to UNC support shall be tracked and logged. Will the log shall be accessible 24 hours, 7 days per week? |
| Support | Address any remote help capabilities. If a P2P dispatcher needs assistance does the proposer have technology that can remote in to a dispatchers system to provide help? |
| Support | Describe how issues and Action items related to UNC support shall be tracked and logged. The log shall be accessible 24 hours, 7 days per week. |
| Support | Describe how a project manager may be appointed that will work closely with the university and ensure new features and functionalities are understood and implemented if desired. |
| Support | Describe the project management plan and implementation process that will be provided for UNC. Include detailed steps. |
| Support | The university retaind the rights to reproduce copies of training materials and materials for its own purposes, and to produce and distribute new training materials including video and/or screenshots of the software for internal use. |
| Support | Describe the formats of training materials that will be available to UNC to meet the needs of P2P staff. |
| Support | How will the vendor ensure that there is adequate training for P2P's own trainers? |
| Support | Describe the extents of marketing and advertising that will be available to UNC for promotion. Also describe how the vendor will work to promote on their own, too. |
| Support | How will the first-time experience for riders be? Describe the tutorial process and introduction for a first-time user. |
| Support | Describe how training vizuals and aids will be distributed to the university. What formats are supported? |
| Support | Address the availability of user manuals needed that include screen captures and easy to follow instructions to assist users through all tasks that they may need to complete. |
| Support | Will a Systems Administration Manual be provided? |
| Driver App | Describe the structure of the GPS system that will be provided. |
| Driver App | Address the possibility of a customizable no show feature. |
| Driver App | Address the ability of a user or dispatcher to change ride destination . |
| Driver App | Will upgrades be included in the licensing cost of the platform? |
| Rider App | Address how the product will alert riders to any cancelled trip(s) |
| Rider App | Will riders be sent an accurate pick up time when a trip is created? |
| Rider App | Will ADA passengers be able to know when their ride pass is out of date? |
| Rider App | Describe the availability of real time vehicle location for when vehicle is close to the pickup location. |
| Reporting | How will standard reports be provided and how often? Will they include fleet and passenger counts? |
| Reporting | Describe the business intelligent tools that are provided from an open API for use. |
| Reporting | Describe the user-friendly tools for use that enable generation of reports using stored data, including data filtering by time period, fare types, services, vehicles, date |
| Reporting | Describe how day-to-day key performance metrics and statistics will be tracked and visualized for P2P staff. |
| Reporting | Will a heatmap of current and historical stop data be provided to dispatchers and UNC staff? |
| Reporting | Address whether the following metrics are accessible in the reporting module for ridership: |
Ridership Data:
Completed Boardings: The total number of passengers who completed trips. This can be different than the total number of trip requests (Total Requests), as there can be multiple passengers per trip.
Average Boardings Per Service Hour: The mean number of Completed Boardings for each hour that service was available.
Boarding Cancellations: The total number of passengers whose trips were canceled.
Cancellation Percentage: The percentage of total cancellations out of total trips.
Cancellation Percentage (No Show): The percentage of no-show cancellations out of total trips.
Total Requests: Total number of trips that have reached a "final state". This includes Completed, Cancelled, and No Drivers Available trips. Trips that are In Progress or Processing are not included in this number.
Completed Requests: The total number of completed trip requests.
No Drivers Available Requests: The total number of trips that the system was not able to fulfill and went to the No Drivers Available Status.
Request Cancellations: The total number of canceled trips.
Request Cancellations (No Show): The total number of canceled trips due to a No-Show.
Avg. # of Requests per Rider: The mean number of Completed Requests per rider.
Avg. Travel Duration: The mean amount of time riders spend onboard a vehicle.
Avg. Travel Distance: The mean distance riders traveled while onboard a vehicle.
Mean Wait Time: The mean wait time of an individual rider during this time period. This only applies to Next Available trips.
Median Wait Time: The median wait time of an individual rider during this time period.
Bookings from Admin Panel: Percentage of total rides that were booked through the Admin Panel.
Bookings from Rider App: Percentage of total rides that were booked through the Rider App.
Avg. # Riders per Request: The mean number of Completed Boardings per Completed Request. (There can be multiple riders per request).
| Feedback | Describe how customers can provide any kind of feedback |
| Feedback | Describe how complaints based on ADA or Title VI disputes will be handled and stored. |
| Feedback | Describe how it will be possible to follow up on complaints, disputes, or any feedback |
| Feedback | Describe the format for feedback reports to be exported. |
File details come from the government source that posted it. Updated .