How to Include Demand Responsive Transport Software in a Public Tender

Demand Responsive Transport (DRT) is becoming an increasingly important part of public transport strategies. Cities, transport authorities and regional governments are using DRT to improve coverage, connect low-density areas, support first- and last-mile journeys, and offer more flexible mobility services where fixed routes are not always efficient.

However, procuring a DRT service is different from procuring a traditional bus route. A successful DRT tender must define not only the vehicles and operations, but also the software platform, booking channels, routing logic, data ownership, reporting requirements and integration with the wider public transport network.

This article explains the main elements that public authorities should consider when preparing a DRT tender or including demand responsive transport software as part of a broader mobility contract.

Start by Defining the Public Transport Problem

Before specifying the technology, the authority should define what the DRT service is expected to solve. Demand responsive transport can support very different mobility needs, and each use case may require different operational rules, software features and performance indicators.

Common DRT use cases include:

• Connecting rural or low-density areas with railway stations, bus hubs or town centres
• Providing evening, night-time or off-peak transport when fixed routes are not viable
• Replacing or complementing low-ridership bus lines
• Improving first- and last-mile access to the public transport network
• Supporting paratransit, accessible mobility or transport for specific user groups
• Managing school, corporate or community transport services

A rural feeder service, for example, may need strong integration with train schedules and flexible pickup points. A paratransit service may require eligibility rules, assisted booking, wheelchair-accessible vehicles and specific customer support processes. These differences should be reflected in the tender from the beginning.

Choose the Right DRT Tender Model

There is no single procurement model for demand responsive transport. The right structure depends on the authority’s internal capacity, existing operator contracts, regulatory context and long-term mobility strategy.

Public authorities usually choose between four main tender models:

• Software-only tender: the authority procures the DRT platform and assigns operations to existing transport operators.
• Operations-only tender: the authority already has the technology or requires the operator to work with a specific platform.
• Integrated software and operations tender: the same contractor provides the technology, vehicles, drivers and service management.
• DRT as part of a multimodal tender: the service is included as a lot or subservice within a broader public transport contract.

A software-only tender can give the authority greater control over data, service design and future scalability. An integrated tender can reduce coordination complexity, especially for agencies with limited internal operational resources. In either case, the tender should clearly define responsibilities between the authority, the software provider, the operator and the customer support team.

Define the Core DRT Software Requirements

The software platform is central to the success of a demand responsive transport service. The tender should therefore include clear technical requirements, while still allowing bidders to propose the most effective way to deliver the service outcomes.

Typical DRT software requirements include:

• Passenger app for iOS and Android
• Web booking portal
• Driver app with route guidance, passenger information and trip updates
• Back-office dashboard for dispatching, monitoring and service management
• Dynamic routing and ride-pooling capabilities
• Real-time vehicle tracking and estimated arrival times
• Booking rules by zone, time window, user type or service category
• Support for fixed stops, virtual stops, door-to-door or corner-to-corner models
• Automated notifications by app, SMS or email
• Multilingual interface and accessibility features
• Reporting dashboard and data export tools

The tender should also explain how the DRT platform must integrate with existing public transport systems. This may include APIs, MaaS platforms, journey planners, ticketing systems, payment providers or GTFS-RT feeds. Without these requirements, the DRT service may operate as a separate system instead of becoming part of the wider mobility network.

Include Booking Options for All Users

DRT is often used to improve accessibility and inclusion. For that reason, the tender should not assume that all passengers will book through a smartphone app.

Authorities should consider whether the service needs to support:

• App booking
• Web booking
• Phone booking through a call centre
• Assisted booking by public employees, caregivers or mobility coordinators
• Recurring bookings for regular users
• Special booking flows for wheelchair users or passengers with reduced mobility

This is especially important for rural transport, senior mobility, healthcare-related transport and paratransit services. A strong DRT tender should define not only the digital experience, but also how non-digital users will access the service.

Set Clear Performance Indicators

Demand responsive transport services should be measured through clear, realistic and service-specific KPIs. These indicators help the authority monitor performance, compare results and adjust the service over time.

Common DRT KPIs include:

• Average waiting time
• Booking success rate
• Passenger trips per vehicle-hour
• Occupancy per vehicle
• On-time pickup and drop-off performance
• Average detour time
• No-show rate
• Cost per passenger trip
• Customer satisfaction score
• App, web and phone booking distribution

The tender should specify how often reports must be delivered, which data must be available in real time, and whether the authority requires access to raw operational data. It is also important to define which KPIs are mandatory from launch and which should be used to optimize the service after an initial pilot period.

Clarify Data Ownership and GDPR Compliance

Data is one of the most important elements of any DRT contract. The authority should clearly define who owns the operational data, how it can be accessed, how long it is stored and how it can be used for future mobility planning.

The tender should include clauses covering:

• GDPR compliance and passenger data protection
• Ownership of trip, vehicle, passenger and performance data
• Access to aggregated and anonymized data
• Data export formats and reporting frequency
• Cybersecurity requirements
• Data portability at the end of the contract

This is particularly important when DRT is part of a long-term public transport strategy. If data access is not clearly defined, the authority may find it difficult to evaluate the service, compare providers or redesign the network in the future.

Avoid Over-Specifying the Algorithm

One common mistake in DRT tenders is trying to define every detail of the routing algorithm. Public authorities should specify the expected outcomes, service rules and performance standards, but avoid limiting innovation by prescribing exactly how the technology must work.

For example, the tender can define maximum waiting times, accepted detour limits, service zones, booking windows, accessibility rules and reporting requirements. The bidder should then explain how its DRT software will meet those requirements through routing, dispatching and pooling logic.

This approach allows the authority to maintain control over the public service goals while giving technology providers enough flexibility to propose efficient solutions.

Define the Implementation and Support Plan

A DRT tender should not only evaluate the software itself. It should also assess how the service will be implemented, launched, supported and improved after deployment.

Authorities should ask bidders to explain:

• Implementation timeline
• Configuration of zones, stops, schedules and booking rules
• Training for drivers, dispatchers and customer support teams
• Passenger communication and launch support
• Technical support availability
• Service monitoring during the first weeks of operation
• Process for making changes after launch

This is especially relevant for pilots or first-time DRT deployments. Even the best platform requires proper configuration, operational coordination and user adoption to perform successfully.

Common Mistakes to Avoid in a DRT Tender

When preparing a demand responsive transport tender, public authorities should avoid several common mistakes:

• Procuring software without defining the service model
• Focusing only on the passenger app and ignoring dispatch, reporting and operations
• Forgetting phone booking or assisted booking for non-digital users
• Not defining data ownership and data export requirements
• Setting unrealistic waiting time or occupancy targets from day one
• Failing to specify accessibility requirements
• Not requiring integration with public transport systems or journey planners
• Using the same KPIs for very different DRT use cases
• Leaving customer support responsibilities unclear
• Creating technical specifications that limit innovation instead of defining outcomes

A well-designed tender should balance clarity and flexibility. It should tell bidders what the public authority wants to achieve, what minimum requirements must be met and how success will be measured.

How to Evaluate DRT Software Providers

The evaluation process should look beyond price. Demand responsive transport is an operational service supported by software, so the selected provider must be able to demonstrate technical capability, implementation experience and long-term reliability.

Useful evaluation criteria include:

• Experience with comparable DRT services
• Quality of the passenger, driver and back-office tools
• Dynamic routing and pooling capabilities
• Integration capacity with existing mobility systems
• Accessibility and inclusion features
• Reporting and analytics capabilities
• Data ownership and portability conditions
• Implementation methodology
• Training and support model
• Scalability for future zones, users or service types

This helps ensure that the authority selects not only a software vendor, but a partner capable of supporting a reliable and adaptable public transport service.

Conclusion

Integrating DRT into a public tender requires more than adding an on-demand mobility component to an existing contract. Authorities need to define the service goals, choose the right procurement model, specify the software and operational requirements, protect their data, and establish realistic performance indicators.

When designed correctly, a DRT tender can help cities and regions create more flexible, inclusive and efficient public transport services. The key is to focus on outcomes, avoid unnecessary technical lock-in, and ensure that the selected demand responsive transport software can support both the launch and the long-term evolution of the service.

Planning a DRT tender? Talk to Shotl about defining the software, operational and data requirements for your demand responsive transport service.