Demand responsive
Empty buses cost more than full ones
Demand-responsive transport runs shared services that follow passengers instead of timetables — end to end, from booking to report.
Does this sound familiar?
Four problems transport planners keep running into
City network or staff shuttle, these four come up in almost every first conversation. Each one has the same answer.
- 01“Our buses run the loop empty”A quiet bus line and a fixed staff shuttle share the same flaw: they run the loop empty as readily as full.Drive where the requests are, and nowhere else
- 02“Our stops are too far apart for a timetable”Scattered villages can’t carry a timetable; neither can a campus with a dozen buildings, two gates and a station a kilometre away.Cover a whole area with a handful of vehicles
- 03“There’s demand after the last bus — just not much”Nights, weekends and shift changes have real demand — just not enough of it, at any one time, to justify a route.Keep people moving after the last fixed run
- 04“We can’t justify the cost per ride”Cost per ride is a budget conversation, not a software one — whether the budget is a transport subsidy or a shuttle contract.Prove the numbers before you change a single route
The answer
Run every vehicle where riders actually need it
Send shared vehicles only where riders have asked to go, and pool compatible trips on the way. That is demand-responsive transport (DRT) — microtransit in North America.
Let riders book by app, web or phone. Let the engine plan the route and the driver follow it. Watch the whole service live, and change it the day the numbers say so.
Set it up your way
- Add stops without building themDraw virtual stops on the map — no poles or shelters to install — and mix them freely with the physical stops you already have.
- Pick riders up at their doorOffer door-to-door pickups to the riders who need them, with wheelchair needs carried into vehicle assignment and pickup times.
- Run several zones as one serviceOverlap your zones so longer trips never force a change of vehicle at a boundary, and let vehicles move between zones as demand shifts.
How it works
How the service actually runs
One mechanism sits behind every service: a request comes in, the engine pools it, the driver is guided, the operator supervises.
FAQ
The questions we hear most
How long does it take to launch?
Typically 6–8 weeks from contract to first passenger, including zone design, driver training and launch marketing.
Can it coexist with our fixed lines?
Yes. Many services keep fixed routes at peak times and switch to on-demand the rest of the day — that's exactly how Vallirana runs.
Can one service cover several towns or zones?
Yes. A single operation can run several operating areas side by side, and zones can overlap so a longer trip doesn’t force a change of vehicle at a boundary. Vehicles are redistributed between areas by the algorithm, following real-time demand rather than a fixed allocation.
What hours can the service run?
Any hours you need, day or night — there is no structural restriction on the window. Service hours are set per vehicle and per weekday, and each time band can offer ride-now requests, scheduled requests, or both.
What about riders without smartphones?
Phone bookings through your dispatchers and web booking are built in, so nobody is excluded.
DRT vs fixed route: when should we use each?
Fixed routes win on dense, predictable corridors — a trunk line or a peak-hour shuttle between station and gate. DRT wins where demand is dispersed or variable: rural areas, off-peak hours, first/last-mile, low-ridership lines, and a campus or site with many origins. Shotl can also protect fixed routes by only assigning on-demand trips where the network doesn't already serve the journey.
