New Software Adoption for Small Transit Agencies Introduction and Background Information
- Date: February 18, 2022
Jump to section
Purpose and Structure
Improving the passenger experience and operating community transit service more efficiently often involves utilizing software-based tools. During the past decade, more and more software options have arisen to assist small transit agencies with their operations and passenger interactions. In some cases, agencies adopt new software in order to upgrade from older software, but in other cases, agencies adopt software to replace so-called “pen and paper” work tasks altogether. In either case, the software may lead to—and/or require—significant internal agency adjustments. Not only will staff need to be educated on how to use the software, but the agency may also need to make important internal changes to accommodate entirely new day-to-day work tasks. In this way, software can have a ripple effect into transit agency operations that may not be entirely clear from the outset.
Additionally, the application of new software at a transit agency can work in two directions. On one hand, existing services and their operations may have software applied to them, in order to increase efficiency, bolster productivity, and improve the passenger experience. On the other hand, software may lead to an agency reimagining how it serves its passengers, since some software increases the viability of modes and digital services that may be entirely new to an agency. Software has the potential to fundamentally transform transit agency services.
In short, a holistic process of software adoption is needed, one that takes all critical factors into account and helps transit agencies navigate unknowns and uncertainty. New software adoption has the potential to range from a relatively simple undertaking to an extremely complex one. While the details of an agency’s individual software adoption process are unique, specific to the intricacies of each agency applying it, the overall structure of the process can be generalized and broken down into a set of steps to follow. This Guidebook provides a four-step process to move from the initial stages of software consideration to later steps involving set-up, operations, and maintenance. While all the details provided within the Guidebook may not be needed for simple cases, they can serve as a checklist of sorts to ensure an agency has considered key aspects.
The four steps are shown below as a cycle of steps that often occur chronologically in the order shown, but do not necessarily follow such a sequence in all cases. For example, while in the midst of Step 3, an agency may need to revisit some of the details associated with Step 1. Adopting new software is a process that is not always linear, and can often involve some surprises. By reading this Guidebook and applying its information, small transit agency staff will be better prepared to understand the full range of activities involved in software adoption.
They will be better able to anticipate challenges and address unknowns; increased awareness will contribute to a more successful software adoption outcome.
Guidebook Focus Areas and Software Types
This Guidebook is targeted primarily at small transit agencies, but medium and larger transit agencies may find it useful as well. Further, it is focused on small transit agencies adopting an already existing “off-the-shelf” software application (i.e., an existing product on the market) and does not include the level of detail needed to guide the creation of a new, customized software application. The Guidebook focuses on specific types of software that are common for small transit agencies, as shown below. Additional software types are explained in further detail in the “Software Functional Types for Small Transit Systems” section of Chapter 3.
Trip planning
Trip planning software enables a customer to view their transportation options online, typically across most or all available choices such as fixed- route transit, demand-responsive transit, bike sharing, walking, and other modes that may be available in an area. This software type enables a customer to quickly compare their options across multiple factors such as trip duration, departure/arrival time, cost, and other factors. More advanced versions of this type of software support “trip chaining” or combining multiple legs of different modes in a single trip (e.g., bike to fixed-route transit or demand-responsive transit to fixed-route transit). This type of software is typically accessed through a website or mobile app. An example of trip planning software is available in N-CATT’s “Promising Practices Guidebook: Transit Technology Adoption”— the Go Vermont! Trip Planner.1 This type of software is a core component of so-called Mobility as a Service (MaaS) applications.
Trip booking and scheduling
Trip booking software enables a customer to book a ride on a transit service and to be provided with information on when the vehicle will pick them up. The trip booking process may be done directly by the customer via a web-based or smartphone app-based application, or may be accomplished by an agent on behalf of the customer using an on-line booking application. Trip booking is very common for demand-responsive transit, and is often directly connected to trip scheduling. Less commonly, fixed-route trips are booked, typically to ensure that riders have an available seat or to control capacity utilization on a vehicle. During the COVID-19 pandemic, interest in trip booking for fixed-route
transit became more common as a tactic to increase safety by controlling the number of passengers and seating arrangements. In some cases, trip booking software is directly connected to trip planning software (i.e., customer reviews options via a trip planner and then books the trip seamlessly). An example of trip booking software is available in N-CATT’s “Promising Practices Guidebook: Transit Technology Adoption”—the Michigan Ride Paratransit app.2
Vehicle scheduling is a fundamental element of all transportation services, and takes different forms for fixed-route transit and demand-responsive transit, with corresponding differences in the types of software required. For small fixed-route transit operations, the vehicle trips to be scheduled are those on a fixed set of routes with pre-determined timetables for the vehicles. Such schedules can often be managed in spreadsheets or very basic software that also includes driver scheduling.
Scheduling software for demand-responsive transit is quite different, and typically works in conjunction with trip booking. The scheduling system is invoked when a customer wants to book a trip, and it determines when that trip request can be accommodated based on commitments already made to other customers. The trip scheduling software manages the capacity of the vehicle fleet used in the service. It determines the routing of each vehicle and how customer pick-ups and drop-offs are sequenced on the vehicle, while also ensuring that customers do not stay onboard for an excessive period of time. The scheduling system is at the heart of the software that manages a demand-responsive transit system. There are many levels of sophistication for such scheduling systems, from those that do little more than organize trips for a dispatcher to schedule manually to those that are fully automated and require little or no human intervention.
1 National Center for Applied Transit Technology. Promising Practices Guide, pp.32-34. Available at: https://n-catt.org/tech-university/promis- ing-practices-guide/ as of February 10, 2021.
2 National Center for Applied Transit Technology. Promising Practices Guide, pp.20-22. Available at: https://n-catt.org/tech-university/promis- ing-practices-guide/ as of February 10, 2021.
Trip payment
Trip payment software enables a customer to pay for their trip online. Such software is tied to multiple payment methods such as credit and debit cards, but may also have options for “unbanked” customers. Such customers may be provided with an option to load value in advance through cash or other payment methods, and then this value is connected to their online account. In some cases, trip payment software is directly connected to trip planning and/or trip booking software (i.e., customer reviews options via a trip planner, books the preferred trip, and then pays in advance).
Trip payment software is typically accessed through a website or mobile app. An example of trip payment software is available in N-CATT’s “Promising Practices Guidebook: Transit Technology Adoption”—the EZfare implementation for seven Ohio transit agencies.3
3 National Center for Applied Transit Technology. Promising Practices Guide, pp.39-42. Available at: https://n-catt.org/tech-university/promis- ing-practices-guide/ as of February 10, 2021.
Software for Demand-responsive Transit Operations
Demand-responsive transit (DRT) is a transit mode that does not operate on a fixed schedule. Instead, it involves customers booking their trips in advance; the booked trips in turn feed into trip scheduling software that is used behind-the-scenes at transit agencies to generate the routing of the vehicles to pick-up and drop-off passengers (sometimes called “vehicle tours”), as discussed previously.
DRT is part of a broader concept of flexible transit services which includes other service models, such as deviated fixed-route service, a hybrid service combining fixed routes and DRT. DRT trips can be booked anytime from several days to a few minutes in advance, depending on how a DRT service is organized. Trips that are booked and taken immediately are sometimes referred to as “on- demand transit” to differentiate from DRT service that requires booking well in advance of service delivery, such as the day prior for most ADA paratransit services. On-demand transit also goes by other names such as microtransit.
DRT services can be provided either directly by agencies using their own staff and drivers to operate the service, or by third-party operations contractors who are fully responsible for the operations components of the service, in some cases providing the vehicles as well. There are several national scale DRT operations contractors (e.g., First Transit, MV Transportation, TransDev) as well as regional scale and local contractors. Some of the latter may also operate taxi services and/or a variety of transportation services under contract to public and private organizations. When an operations contractor is used by a small transit agency for DRT service, it may be a turnkey situation in which the contractor provides the entire service delivery capabilities including all of the DRT software (the vehicles can still be provided by the agency rather than the contractor with a turnkey operation). In other turnkey cases, the agency may provide the DRT software and the contractor must have competency in using a specific DRT software system. If the agency itself operates the DRT service, it will be responsible for the DRT software system. This Guidebook focuses only on software for agency-provided DRT services and for those contracted DRT services in which the agency provides the software system.
DRT ranges in who it serves and where pick-ups and drop-offs occur. It can serve the general population or specific groups such as older adults and riders eligible for certain services (e.g., health care-related trips). The service may be provided directly from one address to another address, such as with curb-to-curb or door-to-door service, but it can also involve pick-ups and drop-offs at street corners or designated locations such as a town center. Further, DRT service may be designed to facilitate pick-ups and drop-offs at fixed-route service connections in an effort for first and last mile connectivity. Some DRT software includes the functionality to support such service variations as deviated fixed-route service (i.e., facilitates the hybrid approach), pick-ups/drop- offs at designated locations such as street corners (i.e., in order to increase service efficiency and productivity), and other operational variations.
While DRT has been around since the 1970’s and exists in several hundred communities in the country (for decades in many of these locations), developments in technology have made it more viable and customer friendly. The key developments include the Global Positioning System (GPS), mobile devices, and cloud computing. GPS enables the current location of any moving item, a person or a vehicle, to be known. When GPS is contained within mobile devices that are increasingly ubiquitous for individual passengers and on-board transit vehicles, the infrastructure is in place for real-time information on the location of passengers and vehicles. With cloud computing, software systems no longer need to operate on computers located on an agency’s premises and be supervised by an agency’s staff (or external contractors). Instead, software becomes a “utility” that one connects to via the Internet; an organization can receive its benefits without concerning itself with the complications of a technology infrastructure. A new generation of DRT/ on-demand transit software is built on top of these infrastructural and technological advances, which makes it possible to connect trip booking directly from the passenger and trip scheduling across the vehicle fleet and vehicle operators—all in real time. Equally important, this software is relatively affordable and requires no long-term investment in equipment and staff by the agency.
Since on-demand transit does not operate on a fixed schedule, the software that supports it requires a number of features to facilitate its operations. Common components are shown below. On-demand transit software is typically purchased as a package that includes most or all of these components. These components are designed to work together in support of on-demand operations—facing the multiple software users including passengers, drivers, and administrative staff.
Software for Multiple Agencies
Software may be adopted by one agency, but in some cases, multiple agencies adopt a software application together. Trip planning, for example, is often taken on as a multi-agency software adoption effort. The purpose of trip planning is for the customer to gain an understanding of all their transportation options, often across large multi- jurisdictional rural or urban areas. Such areas connect homes and jobs, shops and medical facilities, and people travel across them to get what they need—often unaware of how many jurisdictions they cross. Therefore, all transportation modes to all key destinations should be included in the trip planning software and customer app. In order for such a software application to be effective, data will need to be sourced from multiple organizations providing fixed-route transit, DRT, micromobility options such as bikeshare and electric scooter share, and other transportation options. All geographic areas that are commonly traveled across should be included—often requiring several jurisdictions and agencies to be involved. The software system itself becomes the “easy” part of acquiring the capabilities of the software, since without comprehensive data the system has limited value.
Trip booking and scheduling software is less often selected as a common software for multiple agencies. On-demand transit operations software has multiple software components operating as one platform, and by its nature, is highly complex software that each agency will commonly want to select for themselves. The software, with its scheduling and administrative components, is intricately woven with how on-demand operations work on the ground. In contrast, trip planning software reflects services offered and typically does not directly impact operations—making it more able to support the needs of multiple agencies at once.
Trip payment, like trip planning, often needs to be facilitated across multiple jurisdictions. Multi- jurisdictional rural and urban areas sometimes have regional transit fare payment structures that streamline and normalize fares, for instance so that passengers don’t need to pay two agencies to take a cross-jurisdictional trip. In addition to payment structures, there may also be related regional policies such as defining who rides for free. As with trip planning, having a common trip payment software does not necessarily impact operations on the ground.
Further, some areas have regional fare media (e.g., RFID cards) that enable payment through a single medium across multiple transit agencies.
As mobile devices have become more ubiquitous, mobile payment has been leveraged as a regional fare medium. Agencies that never had RFID cards can move directly into mobile payment, transitioning into a more modern fare collection medium. It is possible for trip payment software to be selected for use by multiple agencies across a broader, connected geographic area. However, it is important to not equate the usage of a common trip payment software with fully integrated regional fare structures or fare policy. Some regional agencies decide to use the same mobile payment software because it is easier for them to procure or because they know it is better for the customer to have a single app.
However, in such a situation, there is a range of how integrated the payment structures might be behind the scenes. There may be no integration at all (i.e., simply two agencies on the same software), full integration (e.g., integrated fare structures and fare policy), or something in between.
Software for Integrated DRT Service
Some transit agencies prioritize DRT operations that are integrated with other agencies, often because there is an awareness that passengers are eligible for (i.e., able to use) multiple DRT services. At any point in time, one agency over another may be better positioned to serve the passenger due to their planned schedules, real-time vehicle locations, and number of passengers. There are a few ways that organizations can go about integration including brokerage (i.e., having a central authority that decides which provider will handle a given trip), a common provider (i.e., a single provider that handles trips for multiple eligibility-determined services), and by “exchanging” trips.
With a brokerage or a common provider, the organization providing or allocating the trips will adopt its own DRT operations software, and due to their central role, theirs may be the only DRT operations software in use for the system. In contrast, “exchanging” trips involves leveraging software in order to comingle passengers that are eligible for multiple services handled across multiple providers. In this situation, each provider has their own DRT operations software, and exchanging trips requires using a separate software designed to interact between the multiple DRT operations platforms. In general, a “trip exchange” software involves keeping track of all the services for which a passenger is eligible, the ability for providers to “post” a requested trip for another provider to “claim” (i.e., matching trip requests with the provider best positioned to handle them), and cost reconciliation to track the financial details of each trip (i.e., allocating the cost among providers and funding categories).
In essence, trip exchange software is a secondary software that works between multiple software platforms for DRT operations.
Since DRT services often have adjacent and overlapping service areas, the “comingling” of passengers who are eligible for multiple services can help make the most of a transportation delivery system that has multiple providers operating in the same service area. Applying trip exchange software will not change the overall structure of the way trips are handled, often across a patchwork of providers and services, but it can increase the efficiency of such systems by improving the balance between supply and demand. It can also help improve the passenger’s experience in trying to book a trip, getting denied, trying to book with another provider, and so forth. With an exchange, although a passenger attempts to book with an initial provider that cannot handle it, if another provider ends up accepting the trip, they will receive communications from the initial provider explaining the changes— saving them time and confusion in the process.
A trip exchange can support integrated DRT operations for different situations, such as between multiple transit agencies (e.g., to comingle ADA paratransit clients eligible for multiple, adjacent ADA paratransit services), between a transit agency and a human services transportation or non-emergency medical transportation provider (e.g., to comingle clients eligible for multiple services), and other situations.
The “illustrative project” provided in Chapter 4 explains how a trip exchange software works in further detail.
Guidebook “Quick Content” and Worksheets
The Guidebook “quick content,” at the end of each chapter, includes key takeaways and illustrative projects. Key takeaways are a set of activities that help the reader quickly understand what steps are proposed for the software adoption process. Illustrative projects provide context around the topics mentioned in the chapter; they are real-world examples of how an agency or organization has tackled a specific activity as they navigated the software adoption process. For readers interested in gaining further information beyond the executive summary, but not necessarily planning to read the Guidebook in its entirety, reviewing the quick content is the next best step.
If, after reviewing the Guidebook’s content, a reader is interested in applying the information to their particular situation, a set of worksheets is provided at the end of the Guidebook. The worksheets walk a reader through the activities mentioned in each chapter, with clear guidance on how to apply the information. For some agencies, completing the worksheets individually or during a collaborative session could be the next step in better understanding how their own software adoption process could work. The worksheets help Guidebook users organize their thoughts, pinpoint gap areas, and plan for upcoming efforts.