Ready to Add “Demand-Responsive” Service to Fixed Routes?
How ride-sharing meets paratransit to manage on-demand rides
Picture this: A resident of an outlying area that’s underserved by metro transit is trying out the new “on demand” ride option recently rolled out by their local transit agency. Pulling out his phone, he opens up a rider app for the system, and in much the same way as he’d book an Uber, requests a pickup at his current location and a drop-off by the mall.
Web-based (no software to download or update) platforms are the future of transit, allowing fixed-route transit agencies to incorporate “demand-responsive” functionality into their systems, and, in the process, help agencies deliver equitable transit solutions to more riders—while prioritizing those riders and the rider experience.
Perhaps a municipality is trying to combat residential sprawl or a university wants to expand their SafeRide offering. Maybe a county wants to boost low ridership rates in its larger rural outskirts. Or a local transit agency wants to address the “first-mile-last-mile” challenge that faces residents who are too far from the closest bus stop.
Whatever the scenario, Connect can be a good fit for transit agencies, large and small. And the government agrees…
U.S.D.O.T. Is on Board with DRT
A U.S. Department of Transportation study (https://www.itskrs.its.dot.gov/node/210347) from March 2023 chronicled efforts to enhance a prevailing fixed-route-transit (FRT) system in Tennessee with demand-responsive transit (DRT), highlighting the benefits of blending DRT with FRT.
The study’s title underscored its fundamental conclusion: “Integrating Demand Responsive Applications Across Fixed Transit and Transportation Networking Company Operations Can Address 60 Percent of Trips to Improve Traveler Cost, Time, and Equity Measures.”
According to the study summary:
“One advantage of Demand-Responsive Transit (DRT) is its ability to address the transportation needs of rural populations, particularly in geographically dispersed areas, due to their capability to combine flexible or customizable service with cost-efficiency. Fixed Route Transit (FRT) is adept at catering to the travel demands of urban populations. The coverage of FRT in the low population density areas can be expanded by connecting FRT and DRT.”
Let’s take a closer look at Passio Connect, which is grounded in a popular technology…
Like Ride-Share Platforms (but with a “Human” Twist)
It’s no accident that, for both riders and drivers, Connect operates much like the ride-sharing platforms, Uber and Lyft. The format and layout of those apps are ideal for this task as well.
Yet, the Connect solution takes this a step further, and is built on top of a paratransit on-demand ride system. Why does that matter? Paratransit systems are specifically designed for riders who are elderly, disabled, or in any other way, unable to get themselves physically to an established bus stop on their own. As such, on-demand rides are the focal point of such systems.
More importantly, paratransit systems are grounded in a higher level of care and attention that drivers bring to the task, knowing that their riders, by definition, need more hands-on attention.
So while Connect isn’t ostensibly for elderly/disabled riders, given that, at its heart, it’s built on the paratransit platform, it incorporates the all-important “human touch” features of that system. Yet another way Passio keeps their solutions closely focused on your customers’ experience.
So, Connect incorporates the best of two worlds—the robust functionality and ease of use of ride-sharing platforms and the added layer of customer case built into paratransit platforms.
How Does Connect Work?
When you have an on-demand trip, there are four distinct events that take place, and all are logged into the Connect platform:
1) The driver arrives at the pick-up location
2) The rider is on the vehicle
3) The driver arrives at the drop-off location, and…
4) The rider is off the vehicle.
Let’s look at a real-world example of how Passio Connect functions in real time…
On the left is what the rider sees, while on the right is what the driver sees.
And here’s a thumbnail of the birds-eye-view that dispatch sees.
The above dispatch screen shows “Unassigned” rides in the upper left (i.e., the rides that have been requested, but not yet assigned to a driver); and “Scheduled” rides below that (i.e., rides that have been both requested and assigned to a driver).
On the right side of the dispatch screen are “Available” drivers, and the vehicles they’re driving.
Initiating a Ride Request
The rider logs in to Connect Rider to request a ride, entering their current address and desired destination.
Note the text under both the “Pick Up” and “Drop Off” addresses that says: “Address not in active service area.” This underscores the truly customer-centric nature of this solution, which allows for pick-ups and drop-offs in locations in a specific service zone.
Once the pick-up and drop-off locations are inputted, the map displayed on the rider’s screen will show those pick-up and drop-off locations, and as shown in the right screenshot above, will also display the distance and approximate duration of the trip.
In a typical scenario, the rider chooses the “Picked Up” option” along with the date and time of the requested pick up. Again, like ride-sharing apps, rides can also be scheduled for “now” as well as at a date/time several months in the future (agency determines how far in the future).
Once the rider schedules a trip, their screen will show: “Email confirmation is on the way.”
Riders can also opt to have ride confirmations sent to them via text.
Once the ride is confirmed, it shows up on the dispatch screen in the “Unassigned” section, and at that point, the dispatcher, by noting the location of the ride, compared to the location of available drivers, will assign the ride to a particular driver.
Once the ride has been assigned, the message on the rider’s phone changes from “Email confirmation is on the way” to “Assigned to driver,” and that ride immediately shows up on the driver’s screen:
Once the driver arrives, the rider screen displays the message “Driver is at pick up location.”
The driver’s screen looks like this:
As you see, on the left version of the driver’s screen above, once the rider is physically on the vehicle, the driver will tap the “Rider is On” box in lower-left corner.
Once tapped, that box (on the right screen) changes to a “DO Arrive” (DO = Drop Off) message, which the driver will tap once the ride destination has been reached.
Manual Inputs Confirm Steps Are Completed
The duration of the four distinct stages of a ride noted earlier can vary widely given unique conditions of that ride (for example, an older/disabled/luggage-laden rider may take longer to both enter and exit the vehicle).
As such, confirmation of the successful completion of each stage is manually inputted by the driver, to physically confirm that each stage has been, in fact, successfully completed. Doing so secures the “chain of custody” of that rider throughout the process.
While the technology certainly exists to have those completion points noted and logged automatically—i.e., by the GPS tracking of a rider’s phone, which could indicate once that rider has exited a vehicle—that would necessitate relying on additional external systems.
For that reason, Passio has opted to make those confirmations proactively acknowledged by the driver, who, by definition, is in the best position to know, for a fact, that a rider is both on and off the vehicle. In this way we make it very explicit, with the acknowledgment that the driver is responsible for that rider.
This marriage of both high technology and human intervention is deliberate, and as such, is an intentional feature, not a bug.
The Ride Is Under Way
Once the ride departs is underway, the driver’s screen will display the route on the map, while
the riders screen will display the message “Heading to drop off location.”
The Ride Arrives at Destination
Once the vehicle arrives at the rider’s destination, the driver taps are the “DO Arrive” button, which, then changes its message to “Rider is Off.”
(NOTE: The ride status buttons on the driver’s screen are always showing the next step in the process. (i.e., when a ride is underway, for example, the driver’s screen will show “Rider is Off,” which will only be tapped once the rider is, in fact, off the vehicle.)
Once the rider is officially off the vehicle—after, for instance, the driver helps them out of the vehicle, or helps them with packages/luggage—the driver will tap the “Rider is Off” button, which will then default to “PU arrive” (PU = pick up), in preparation for the next pick up, or, at that point, the vehicle can return to its fixed route.
On the rider’s side, their screen will now reflect the official end of their trip by displaying the message, “Trip has been completed.”
Also Works for Small “Dispatch-Less” Systems
The Passio Connect platform is ideal for transit systems with two to four dispatchers, and 10–20 vehicles, with the dispatchers managing that traffic.
Yet, many transit systems are far smaller—fielding one or two drivers with iPads, handling, perhaps, university-based SafeRide program, and without the funding to have a dispatch-based solution. Connect can work just as well for these more modest operations.
The system operates the same way; a rider requests her ride on the same app as she’d use in in a larger system.
Yet, unlike the above-described scenario where ride requests are funneled into dispatch, which then assigns those rides, Connect allows smaller systems to bypass the dispatch step, and choose an option to auto-approve ride requests.
Those approved rides immediately display in the driver’s screen, at which point the driver can manually assign the ride to themselves, by tapping the “Assign trip to me” link at the top of the driver screen.
That trip now shows up in the driver’s manifest—minus any intervention from a dispatcher.
Systems with more than five drivers will want to have a dispatcher, but those with fewer than that can leverage this “direct-to-driver” short cut, eliminating the dispatcher from the equation.
Systems that choose to operate without formal dispatchers can set up Connect to send all approved trips to all drivers. At that point, one of those drivers—perhaps, given his geographic proximity to the pick-up location, or because he knows other drivers aren’t nearby or have taken a lunch break—will assign that ride to himself.
OR, Driver as Dispatcher…
Alternately, smaller transit systems can assign one driver as a de facto dispatcher, who, in turn, can either assign the ride to themselves, or manually assign it to another driver (i.e., to “Tim Mahoney” in the screenshot below:
The tipping point is generally around five drivers, above which, you either need to have a dispatcher, or, if you’re funneling auto-approved rides directly to your drivers, one of those drivers should act as a dispatcher.
Web-Based with Simple Integration
Passio Connect is completely web-based (no software to download or update) with log-ins. While it’s a separate platform, it enjoys back-end integration with our cloud-based “Main Brain” console, Passio Navigator. Users will define their service zones within Navigator, and Connect will pull those values in.
Build Stronger Connections with Your Ridership.
Passio Connect is a simple add-on that marries the best features and functionality of both ride-sharing and paratransit platforms. Use it to build a new level of flexibility into your transit system while reaching more underserved riders and boosting both your customer-service delivery and rider loyalty.
Next Stop: Learn More!
Reach out today and learn how Passio Connect can elevate both your customer service and the rider experience. For more information or to request a demo, contact Passio at [email protected] or call 678-825-3456.
