National Academies Press: OpenBook

Development of Transactional Data Specification for Demand-Responsive Transportation (2019)

Chapter: Appendix 8: Request for Proposals (RFP) Language

« Previous: Appendix 7: Marketing Document
Page 164
Suggested Citation:"Appendix 8: Request for Proposals (RFP) Language." National Academies of Sciences, Engineering, and Medicine. 2019. Development of Transactional Data Specification for Demand-Responsive Transportation. Washington, DC: The National Academies Press. doi: 10.17226/25619.
×
Page 164
Page 165
Suggested Citation:"Appendix 8: Request for Proposals (RFP) Language." National Academies of Sciences, Engineering, and Medicine. 2019. Development of Transactional Data Specification for Demand-Responsive Transportation. Washington, DC: The National Academies Press. doi: 10.17226/25619.
×
Page 165
Page 166
Suggested Citation:"Appendix 8: Request for Proposals (RFP) Language." National Academies of Sciences, Engineering, and Medicine. 2019. Development of Transactional Data Specification for Demand-Responsive Transportation. Washington, DC: The National Academies Press. doi: 10.17226/25619.
×
Page 166

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

164 SCOPE OF SERVICES: Service Provider Appendix 8: Request for Proposals (RFP) Language Moving into the digital age requires that the software used by transit agencies be able to seamlessly exchange data. Agencies procuring software are the ones that must require this capability, opening up the future for an array of technological solutions. There are costs for a vendor to adapt their software to a standardized data format, but once incurred this cost can be amortized across all agencies that procure software. This means that the costs for an individual agency will be small but it will open up many possibilities for sharing data across platforms. This appendix contains two sets of text that could be edited and used in a request for proposal (RFP) that would adhere to or support the use of the proposed DRT transactional data specification in procuring paratransit/DRT/micro-transit scheduling software. The first part is language that for use by a transit agency and/or other DRT service providers in a request for proposal for procuring a paratransit or DRT/micro-transit service provider where the provider will include a paratransit/DRT/micro-transit scheduling system as part of the services provided. The second part is language that could be used by an agency that is procuring DRT software and/or a technology vendor. [Brackets] indicate text that should be inserted prior to use. The following RFP language can be adapted based on what the transit agency has in place, intends to implement over the period of the service contract, and is purchasing through the RFP. One year is suggested for when the software adaptations are required to be in place but this may be adjusted to reflect the needs of the transit agency. CASE 1-A: Transit/Paratransit agency does not provide software and requires service provider to bring a scheduling/dispatch solution as part of the service proposal. CASE 1-B: Transit/Paratransit agency has software licenses for their directly operated services but allows the proposer to bring a different dispatch platform for the contracted services. [Transit agency name] is adopting the [TCRP G-16 transactional data specification] for demand responsive transportation service trip reservations, scheduling, and dispatching. Over time this will enable {Transit agency name] to use the data in a variety of technology applications and to readily share data between our agency and the service contractor and with other agencies such as grant or funding partners or coordination partners. Over the term of the agreement resulting from this RFP, [Transit agency name] may begin reporting such data to the state or may use a mobile app to support first- or last-mile trips.

165 CASE 1-A: The trip data in the [TCRP G-16 transactional data specification] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., rider name, scheduled pickup/drop-off times and locations, fare to be collected, vehicle type needed, notes, phone number). The scheduling system proposed must be capable of sharing such data electronically via an export file (e.g., .xls or .csv format) or through an Application Programming Interface (API). Proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing. This must be in place by the beginning of year two of the contract. The [Transit agency name] also requires (1) proposers to retain independent trip records for backup and auditing purposes and (2) for the successful proposer to use terminology consistent with the [TCRP G-16 transactional data specification] data descriptions in all reporting and forms. CASE 1-B: The trip data in [transit agency’s existing paratransit software] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., rider name, scheduled pickup/drop- off times and locations, fare to be collected, vehicle type needed, notes, phone number). This data can be shared electronically via an export file (e.g., .xls or .csv format) or through an Application Programming Interface (API). However, proposers may also bring in their own dispatch platform. If a separate proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing between [transit agency’s existing paratransit software] and the proposer’s dispatch platform, including the capacity to share vehicle locations, estimated time of arrivals, and trip performance status (e.g., scheduled, completed, canceled, no-show). The [Transit agency name] also requires (1) proposers to retain independent trip records for backup and auditing purposes and (2) for the successful proposer to use terminology consistent with the [TCRP G-16 transactional data specification] data descriptions in all reporting and forms. Proposers that do not currently use any dispatch software to accomplish the above data integration may still respond to this RFP but should indicate how they will ensure that trip data provided by [transit agency name] will be dispatched accurately and in a timely manner, as well as how they will communicate trip status updates, report on historical performance, and generate/audit invoices. Proposers that do not have sufficient dispatch technology are also encouraged to partner with other potential service providers to leverage a common dispatch platform that can accomplish the above data integration. All proposers are strongly encouraged to format the data and data transactions used for this service such that the data are readable and useable by any other software that also makes use of the [TCRP G-16 transactional data specification].

166 SCOPE OF SERVICES: Software/Technology Vendor The following language can be included in an RFP for procuring DRT trip scheduling and dispatch software. How this language is adapted for your RFP will be determined by on what the transit agency has in place, intends to implement over the period of the service contract, and is purchasing through the RFP. One year is suggested for when the software adaptations are required to be in place but this should be adjusted to reflect the needs of the transit agency. For example, if the procuring agency intends to use the data immediately as part of a coordination project, the RFP language should specify both the timing and form in which data needs to be exported. If the agency intends to, at a later time or an unspecified time, undertake a project that requires shared data (e.g. developing a mobile app that will allow riders to identify if any DRT vehicles could be used for a first-mile or last-mile trip or sending data directly to a grant funding partner such as the state), this too should be stated and may result in allowing a longer time to adapt the software. [Transit agency name] is adopting the [TCRP G-16 transactional data specification] for DRT trip reservations, scheduling, and dispatching. Over time this will enable {Transit agency name] to use the data in a variety of technology applications and to readily share data between our agency and the service contractor and with other agencies such as grant or funding partners or coordination partners. Over the period the [Transit agency name] intends to use the dispatch software being procured through this RFP, [Transit agency name] may begin reporting such data to the state or may use a mobile app to support first- or last-mile trips. The trip data in the [TCRP G-16 transactional data specification] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., customer name, scheduled pickup/drop-off times and locations, fare to be collected, vehicle type needed, phone number). This data can be shared electronically via an export file (e.g., .xls or .csv format) or an Application Programming Interface (API). Proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing among dispatch platforms, including the capacity to share vehicle locations, estimated time of arrivals, and trip performance status (e.g., scheduled, completed, canceled, no-show). Proposers that do not currently use any dispatch software to accomplish the above data integration may still respond to this RFP. If this is the case, the proposer shall indicate how it will ensure that trip data provided by [transit agency name] will lead to trips that will be dispatched accurately and in a timely manner, as well as how it will communicate trip status updates, report on historical performance, and generate/audit invoices. A proposer that does not have sufficient dispatch technology is also encouraged to partner with other potential service providers to leverage a common dispatch platform that can accomplish the above data integration. Proposers must retain independent trip records for backup and auditing purposes. Separate trip records and reports must also be maintained for premium service trips (if applicable), as these trips may be reserved directly with the provider and may not be scheduled by [transit agency name].

Development of Transactional Data Specification for Demand-Responsive Transportation Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

In the current U.S. climate of on-demand transportation services, the development of transactional data specifications for demand-responsive transportation (DRT)—sometimes referred to as “on-demand services”—will help facilitate interaction between software systems that manage DRT services in the United States.

The TRB Transit Cooperative Research Program's TCRP Research Report 210: Development of Transactional Data Specification for Demand-Responsive Transportation documents the development of the new data specifications for DRT.

A primary purpose of a transactional data specification is to enable DRT services in the U.S. to more fully and easily participate in an era of “New Mobility” by facilitating interactions among the software systems that manage them. New mobility refers to a new generation of technology-enabled urban transportation services that include bike sharing, car sharing, electric scooters, and on-demand transportation services operated by both private-sector and public-sector entities, including Uber and Lyft as well as public transit agencies.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!