Demand-responsive transport, or DRT, is usually sold as a rural answer: low density, few passengers, a fixed route that cannot be justified. That framing has shaped the market, and it has made DRT easy for large operators to dismiss as something for someone else's network.
The more interesting use of DRT is the opposite case. Large metropolitan and regional operators are deploying it as a complementary layer on top of a high-capacity fixed network, to solve two problems the fixed network handles badly: the last mile from a trunk corridor, and off-peak hours when a full timetable is indefensible but zero service is unacceptable.
The operational question that follows is the one this article is about: how do you run that layer without standing up a parallel organisation to dispatch it.
What DRT solves for a large network specifically
The last mile from a trunk corridor. A high-frequency corridor moves passengers efficiently along an axis and does nothing for the two kilometres either side of it. Extending fixed routes into those catchments produces low-occupancy branches that drag corridor performance. A flexible layer feeding the corridor keeps the trunk clean and the catchment served.
Off-peak and evening service. A fixed timetable that runs until midnight at daytime headways is expensive. Cutting it at 20:00 shifts a political cost onto the authority. A demand-responsive evening layer over the same territory holds coverage at a fraction of the vehicle hours.
Industrial and peripheral shift patterns. Peripheral employment sites generate concentrated demand at times no public timetable is built around. These are naturally flexible services, and they are usually the easiest DRT business case to prove because the demand is known in advance.
Temporary substitution. Works, closures and rail replacement create service holes with a defined end date. Standing up a flexible service is faster than re-planning fixed routes twice.
In every one of these cases DRT is not replacing the network. It is extending it, which changes the requirements substantially.
Why the rural DRT model does not transfer
Most DRT tooling was built for a small, self-contained service: a handful of vehicles, one operating area, a booking line, a dispatcher who knows every driver by name. Applied to a large operator, that model breaks in four places.
It assumes dedicated vehicles. A large operator wants to use vehicles and drivers that also run fixed services, because DRT demand alone does not fill a duty. That requires the flexible layer to share the same resource pool as the fixed network, not sit beside it.
It assumes a dedicated dispatcher. At small scale, a person can manage the day. At scale, human dispatch does not extend past a few dozen daily trips before it becomes the constraint. The layer has to be exception-managed, not managed.
It assumes one operating area. Large operators run multiple depots with different vehicle types, different collective agreements and different territories. A single-zone tool multiplies into one tool per zone, and the operator inherits the reconciliation.
It ignores the interface with the fixed network. For a feeder service, the entire value is the connection. If the flexible layer cannot see that the trunk departure is running six minutes late, it delivers passengers to a stop the bus has already left, and the service loses credibility in a week.
That last point is the decisive one, and it is where a standalone DRT product structurally cannot compete with a flexible layer that shares data with the fixed network.
What running DRT at scale actually requires
One resource pool across fixed and flexible service
Drivers, vehicles and duties should be planned once. If the flexible layer holds its own separate roster, the operator manages two conflicting versions of driver availability and discovers the conflict at 06:00. Sharing the pool also means DRT can absorb slack in existing duties rather than requiring new ones, which is usually where the business case is.
Automated assignment, with human exception handling
The system should assign trips to vehicles and sequence them without intervention, and escalate only what it cannot resolve: an unservable request, a capacity conflict, an accessibility requirement it cannot meet. The staffing model is one controller handling exceptions across a whole territory, not a dispatcher per zone.
Live awareness of the fixed network
A feeder service needs the trunk network's real-time state. When the corridor departure slips, the connection has to adjust or the passenger has to be told. This only works when the flexible layer and the fixed network share a data model rather than exchanging files.
Booking channels that match the actual passenger
An app-only DRT service excludes a meaningful share of the demand, particularly off-peak and in peripheral areas. Phone booking, standing reservations for recurring trips and simple web booking are not legacy concessions, they are what keeps the service usable for the people who need it most.
Reporting the authority will accept
Cost per passenger, occupancy, refused requests, deviation from promised pickup windows. Flexible services attract more scrutiny than fixed ones because they are newer and their cost per passenger is easier to attack. Producing that evidence automatically is what keeps the service funded past its pilot.
How to size the first deployment
The most common failure is starting with the hardest territory. Operators launch DRT in the lowest-density area they serve, because that is where fixed service is least defensible, and then evaluate the concept on a case with structurally poor economics.
A better first deployment has three properties: demand that is at least partly predictable, an existing trunk connection to feed, and a defined evaluation window. Peripheral employment sites and evening service over an existing daytime corridor both fit. Both also produce numbers within a few months rather than a few years.
The second most common failure is treating the pilot as a separate system. If the pilot runs on standalone tooling with its own vehicles and its own dispatcher, it will show a cost per passenger that no consolidated deployment would ever produce, and the concept dies on evidence from a configuration nobody intended to scale.
Frequently asked questions
Does DRT reduce total operating cost?
Not usually on its own. It reduces cost for coverage that would otherwise be served by low-occupancy fixed service, and it makes coverage possible where fixed service was going to be cut. Evaluate it against those alternatives, not against the network average.
How many vehicles does a DRT layer need?
Fewer than operators expect, if the vehicles are shared with fixed service. Dedicated fleets are what make DRT expensive, not flexible operation.
Can DRT run without a dispatcher?
It can run without a dispatcher per zone. It cannot run without a controller handling exceptions. The realistic target is one person covering a wide territory, supported by automated assignment.
Is DRT compatible with existing real-time passenger information?
It has to be. Passengers making a feeder trip need the trunk departure and their flexible pickup in one view. If the two live in separate systems with separate feeds, the connection experience fails.
The framing that matters
DRT at scale is an operating layer, not a product category. Judged as a standalone service it looks marginal. Judged as the thing that lets a trunk network stay a trunk network while still covering its catchment, it is straightforwardly useful, and it is measurable.
If you are evaluating a flexible layer over an existing multi-depot network, Pysae's team can walk through how demand-responsive trips are assigned against the same drivers, vehicles and real-time data as your fixed services.