On-demand ridepooling & demand-responsive transport dispatch

Fixed bus lines are inefficient in rural areas and at night, while individual taxis are expensive. On-demand ridepooling (demand-responsive transport, DRT) lets passengers book a ride in an app or by phone; a dispatch engine bundles compatible requests into shared vehicles, picks virtual stops and updates routes within seconds. The optimisation core is classical (heuristics and solvers), increasingly combined with ML demand forecasts and learned rebalancing policies. It is a strong EU public-sector topic because municipalities and transport associations fund and regulate it.

Problem & value

• Today: rural and off-peak public transport runs empty buses on fixed timetables, or call-taxi/Anruf-Sammeltaxi services booked hours ahead and dispatched by hand. Paratransit (accessible transport) is dispatched manually in many places.
• AI/optimisation value: serve more passengers per vehicle-hour via pooling, keep wait time and detour within service guarantees, reduce empty kilometres through demand-aware rebalancing, and let operators test service-area, fleet-size and tariff changes in simulation before spending funds.
• Evidence: German research on ridepooling (e.g. the KIT/TUM accompanying research on MOIA in Hamburg, 2019–2021, and federal-funded evaluations) reports that pooling efficiency and utilisation depend strongly on demand density; DRT is typically a complement to fixed-route service, not a replacement. Treat vendor KPI claims as scenario-specific and ask for evaluations of comparable areas [1][2].
• Legal frame (DE): the 2021 Personenbeförderungsgesetz (PBefG) reform created "gebündelter Bedarfsverkehr" (pooled on-demand traffic, §50) as a licensable mode and allows integration into local transport plans and tariffs [3].

Variants

• Rural DRT / ÖPNV feeder: virtual stops, service areas and time windows tied to rail timetables.
• Urban ridepooling: high-density shared rides, dynamic pricing within tariff rules (see OPT-004).
• Paratransit / accessible transport: wheelchair slots, escorts, strict rules; often subscription-based.
• Autonomous shuttles: the same dispatch layer with remote supervision and geofenced operation.
• Corporate/campus shuttles and hospital transport: closed user groups, scheduled pre-bookings.
• Private use: not applicable; end users interact via apps only.

How it works

1. request (app / phone / voice bot)
2. geocoding + virtual-stop snapping + eligibility/fare check
3. insertion heuristic: feasible vehicle/route candidates under wait, detour, capacity, shift limits
4. assignment (batched matching every few seconds | greedy insertion)
5. quote & confirm
6. driver app routing, live ETA updates, no-show/late handling
7. rebalancing of idle vehicles using demand forecast
8. offline: simulation, fleet sizing, service-area tuning, reporting

• Dispatch core: solves a dynamic dial-a-ride problem. Production systems use insertion heuristics plus local search or batched assignment; exact MIP solvers are used mainly for offline planning and benchmarking. Latency target is seconds per request.
• Forecasting: gradient boosting or deep time-series/spatial models predict demand per zone and time slot (events, weather, school times) to drive rebalancing and shift planning (PRED-019).
• Learning-based policies: reinforcement learning for rebalancing and pricing is an active research field with some pilots; most production engines still rely on tuned heuristics because they are predictable and auditable.
• LLM role: conversational booking in chat/voice, multilingual passenger support and operator copilots that explain KPI changes; LLMs do not make the dispatch decision.
• Human-in-the-loop: control-room staff handle exceptions (breakdowns, special needs, disruptions), approve service-area/tariff changes and take over manual dispatch.

Data preparation

Data needed: demand history (bookings, requests), vehicle and shift data, road network and travel times, stop locations and virtual stops, accessibility needs and tariff rules. In a transport company or municipality this lives in booking and dispatch systems, the fleet management or telematics tool, shift planning in Excel, the ERP and, for scheduled-service history, timetable files (GTFS) and paper driver logs.

Typical gaps: no history before launch (cold start), booking data with personal identifiers, inconsistent stop names, shift plans as spreadsheets, outdated road networks and missing data on no-shows and cancellations.

Preparation steps: derive a demand estimate from ticketing, school and commuter data or from a pilot; build a clean stop and zone table; load OpenStreetMap and GTFS data and validate travel times against real GPS traces; structure shift plans; pseudonymise booking data before analysis. Because GPS and booking records relate to passengers and drivers, define retention periods early.

Expect a medium share of effort, about 20-30 percent. See PREP-005 for exports from booking systems, PREP-011 for shift spreadsheets, PREP-022 for pseudonymisation, DATA-003 and GUIDE-003.

Implementation paths

Which path for whom

• public (A): Municipalities and transport associations need a working service quickly; mature EU-hosted platforms (e.g. ioki, Via) bring dispatch, booking app, passenger-licence know-how and operations support as a service.
• enterprise (B): Operators with existing fleet, ticketing and telematics systems usually need dispatch integrated into their own landscape, using routing and VRP solvers plus cloud APIs.
• developer (C): Open solvers such as VROOM, OR-Tools and OSRM run on modest hardware and give full control over pooling logic, with a data-sovereign setup.

Path A — Buy (recommended for operators and municipalities)

• Specialised DRT platforms: ioki (DE; sale by Deutsche Bahn to the Benteler Group announced January 2026), MOIA (Volkswagen, DE), door2door (DE), Padam Mobility (FR), Spare (CA, widely used in Europe), Via (US, many EU contracts), Liftango (AU). Typical scope: routing engine, passenger and driver apps, back office, APIs to ticketing and clearing.
• Check: EU hosting and GDPR processor contract, PBefG/regional tariff integration (e.g. deutschlandticket handling), accessibility features, open interfaces (GTFS-Flex, NeTEx, VDV 463/ OJP), data ownership on exit, and evaluation references in comparable areas.
• Choose A when: you are a transport authority or operator without an in-house routing team.

Path B — Build on cloud APIs

• Routing/ETA: Google Maps Platform Routes API, HERE, TomTom or Mapbox matrix APIs; for EU data residency also open options below.
• Optimisation: Google OR-Tools (routing library), Gurobi/CP-SAT for planning models, or commercial route engines such as Hexaly or PTV (DE) for tours; real-time insertion logic usually needs custom code.
• LLM layer: a frontier or EU model (Mistral, Claude, GPT, Gemini in EU regions) for booking dialogue and operator copilot with function calling into the booking API.
• Choose B when: you need custom service rules or want to integrate into an existing MaaS app.

Path C — Self-host (open source)

• Routing: OSRM, Valhalla or GraphHopper on OpenStreetMap data; OpenTripPlanner for multimodal journey planning with GTFS-Flex.
• Solvers: Google OR-Tools, VROOM (vehicle routing), PyVRP (HGS-based), OptaPlanner/Timefold (Java).
• Simulation: MATSim with its DRT module and SUMO for scenario studies; research code for pooling policies.
• Forecasting: LightGBM, Prophet or time-series foundation models (Chronos, TimesFM).
• Hardware: HW1 suffices (CPU servers); GPU only for LLM voice/chat layer (HW2) or RL training.

Path D — Custom training

Worth it for large operators with months of booking logs: train zone-level demand models and RL-based rebalancing/pricing policies, always validated in a simulator replaying real requests before live A/B tests. Needs request logs, trip traces and vehicle states; a few months of data at minimum, ideally across seasons.

State of the art (2026)

• Dispatch: batched matching with insertion heuristics remains the production workhorse; learned value functions and graph neural networks improve assignment in research and in some vendor pilots, but robust gains over tuned heuristics are context dependent.
• Simulation first: agent-based simulators (MATSim, SUMO) are standard for fleet sizing and service-design decisions before launch.
• Interoperability: GTFS-Flex and NeTEx/VDV standards enable DRT inside journey planners and ticketing so that on-demand legs appear next to fixed lines.
• Autonomous operation: pilots with driverless shuttles in Europe (e.g. KIRA, ALIKE and similar federally funded projects) keep a remote operator in the loop; scale remains limited.
• Limits: pooling efficiency collapses at low demand density; forecast errors around events; fairness issues (underserved areas or passengers with disabilities get rejected more often); cost per passenger often stays above fixed lines, so benefit is accessibility, not savings.

Shared resources & combinations

• Same stack (optimization-solver + time-series): OPT-001 vehicle routing, OPT-019 field-service dispatch, OPT-005 replenishment planning share solver and routing infrastructure.
• Upstream: PRED-019 traffic and mobility demand forecasting, OPT-013 timetabling for fixed line integration.
• Downstream/adjacent: OPT-021 EV fleet charging (electric DRT fleets), OPT-020 disruption recovery, OPT-025 traffic signal control (bus priority).
• Routing engines and OSM extracts can be shared across all mobility use cases.

Effort, cost & KPIs

• Path A: 3–6 months from tender to launch including licences, vehicle contracts and integration; cost is typically per vehicle-hour or per ride plus operator cost. Vehicle and driver operation, not software, dominates budget.
• Path B: 6–12 months for an MVP with in-house team.
• Path C/D: 12+ months, specialised OR/ML team required.
• KPIs: passengers per vehicle-hour, pooling rate, average wait and detour, rejection rate, empty-kilometre share, cost per passenger, share served in accessibility groups, CO2 per passenger-km, feeder share to rail stations.

People & change

Management and the political or association sponsor set service goals and budget. The operations lead owns dispatch rules; drivers and control-room dispatchers are the end users and need early involvement, since the system assigns their routes and breaks. IT covers telematics and interfaces. Customers (passengers) must be informed about data use in the app, and accessible service needs involve user representatives.

Works council: yes in most cases. Driver GPS tracking, shift and performance data make the system objectively suited to monitor behaviour, so co-determination under §87(1) no. 6 BetrVG applies; a works agreement on data use, retention and no individual performance rating is advisable. Inform the council in good time (§90 BetrVG) and consider an AI expert (§80(3)). Public operators involve the staff council (Personalrat).

Data protection: passenger movement data is personal and sensitive in aggregate; involve the DPO early, conclude an AVV with the platform vendor and perform a DPIA. Run a pilot in one zone or time window, with dispatchers able to override assignments. Typical concerns are job loss and surveillance; address them with transparent rules, limited data access and driver feedback loops. Provide AI literacy support for dispatchers and drivers. See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: minimal risk for dispatch optimisation; not an Annex III system. Transport safety components for road traffic management in Annex III cover critical infrastructure control, not passenger booking. If fully autonomous vehicles are used, vehicle type approval rules apply separately. Passenger chatbots need Art. 50 disclosure; AI literacy (Art. 4) applies to staff [4].
• GDPR: location data of trips is personal and revealing (home, work, health facilities, religion). Data minimisation, short retention, pseudonymised analytics, aggregated open data for planning; special categories possible for accessibility needs (Art. 9) so use explicit consent and restricted access. DPIA is advisable for systematic location processing [5].
• Transport law: PBefG licences, tariff and subsidy rules, working-time rules for drivers.
• Fairness and service obligation: avoid algorithmic redlining of low-demand areas; set minimum service guarantees and audit rejection rates by zone.
• Operational risks: engine outage (fallback to manual dispatch), driver acceptance, vendor lock-in.

Getting started

1. Define goals (accessibility, feeder, cost) and the service area; check demand with existing ticketing, mobile data or surveys.
2. Simulate the service in MATSim/SUMO with synthetic demand to size fleet and virtual stops.
3. Shortlist 2–3 Path A vendors; request evaluations from comparable regions and open-interface proof.
4. Run a time-limited pilot with clear KPIs and a DPIA; keep a manual dispatch fallback.
5. Add demand forecasting and rebalancing after 3+ months of booking data.

Sources

1. BMDV / German federal mobility research on on-demand ridepooling (mFUND, Modellvorhaben) — https://www.bmv.de/DE/Themen/Mobilitaet/mobilitaet.html
2. ioki — on-demand mobility platform — https://ioki.com
3. Personenbeförderungsgesetz (PBefG) — https://www.gesetze-im-internet.de/pbefg/
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Google OR-Tools — https://developers.google.com/optimization
7. VROOM project — https://github.com/VROOM-Project/vroom
8. MATSim DRT contrib — https://matsim.org
9. GTFS-Flex specification — https://gtfs.org/extensions/flex/
10. MOIA — Forschung (accompanying research on ridepooling with KIT/TUM) — https://www.moia.io/de-DE/forschung