RFP and technical resources

Everything you need to specify demand-responsive transport — without naming a vendor

Written for the two people who read a tender before it is published: the officer drafting the requirements, and the technical or legal reviewer who has to verify them. Drawn from tenders we have answered across small and mid-size towns and regions. Nothing here is gated.

Requirement library Get the editable template

Platform facts for your compliance annex

Delivery model: SaaS, cloud-native
Hosting: AWS Ireland (EU)
Infrastructure certification: ISO/IEC 27001
Availability: Above 99.5%
Accessibility target: WCAG 2.1 AA guidelines
Passenger channels: iOS, Android, web
API: REST, JWT (RFC 7519)
Tenancy: Multi-tenant, data isolated
Branding: White-label available
In-vehicle hardware: Supplier-independent
Environmental policy: Published, on request
Anti-bribery and code of ethics: Published, on request

Requirement library

Wording you can lift into a specification

Grouped the way tenders are structured. Each line is a capability stated plainly, so you can require it of any bidder — not only of us.

Get all of this as an editable document →

01Platform architecture

Software-as-a-Service, cloud-native, with passenger apps, driver apps, an operations control centre, an optimisation engine and an integration layer sharing operational data in real time.
Modular components, so new functionality, integrations and configurations can be introduced without interrupting a running service.
Several service models coexisting in one deployment — fixed routes, semi-flexible lines and fully dynamic on-demand operation across different areas and hours.
Multi-tenant operation, where credentials grant access only to the data belonging to the corresponding client.

02Passenger experience

Native iOS and Android applications plus a web application, all covering the full booking journey.
White-label option: interface, colours, logos, terminology and legal documents adapted to the authority's or operator's identity.
Registration through a verified mobile number with one-time-password validation; additional fields (email, date of birth, identification, eligibility) configurable per deployment.
Immediate and scheduled journeys, multi-ride bookings, one-way or return trips, several passengers in one booking, and an accessibility flag such as wheelchair use.
Estimated pickup and arrival time, and applicable fare where fares are enabled, shown before the passenger confirms.
Multimodal planning: the passenger sees the end-to-end journey including public transport connections, stops and departure times, not only the on-demand leg.
Real-time vehicle tracking and journey notifications.

03Driver experience

Native iOS and Android driver applications plus a web application, with authentication and session management.
Turn-by-turn navigation using live traffic from the routing provider, with the sequence of pickups and drop-offs updated as the operation changes.
Driver-side trip execution: passenger boarding and no-show handling, break and shift status, and vehicle availability that immediately stops new assignments when set.
Route deviations caused by traffic or incidents are registered automatically and the route re-optimised.
Hardware-independent: the operator may supply in-vehicle devices and mounts, or ask the supplier to include a recommended rugged Android tablet and data plan.

04Operations and customer service

Browser-based dispatching and control interface, with no local installation.
Differentiated roles: controller accounts that create, view and cancel bookings on a passenger's behalf; administrators who additionally manage vehicles, drivers, shifts, zones, schedules and permissions.
Access limited to the areas and operations each user is authorised for, revocable at any time by an administrator.
Real-time status of every vehicle and booking across the operation, plus historical consultation.

05Service configuration

Service areas defined and edited by the operator, including creation, activation and deactivation of virtual stops, map visualisation, filtering by status and export for reporting.
Door-to-door operation without fixed stops, from origin address to destination address — the model most suited to accessibility-oriented services.
Operating hours per vehicle, per weekday and per request type, with exceptions for public holidays or planned reductions taking precedence over the general schedule.
Custom street rules for prohibited streets or turns, such as narrow lanes or bus-only sections, which the routing engine must respect.
Subareas and movement restrictions, so certain stops can be reserved for certain vehicles, and overlapping areas that share a subset of stops.
Configuration changes made directly by the operator, with or without supplier intervention.

06Non-functional requirements

Service availability above 99.5%, on independently scalable microservices behind redundant load balancers, with staging separated from production.
A travel proposal returned to the passenger within seconds of the request, balancing waiting time against solution quality.
A defined incident-response SLA, with resolution times differentiated by severity between blocking and non-blocking incidents.
Full event logging: vehicle movements with time and coordinates, driver application heartbeats, breaks and shift changes, booking lifecycle events, registered users and dashboard access logs.
Multi-language passenger app, driver app and dashboard, with further languages addable during project configuration.
WCAG 2.1 AA as the accessibility target, with native screen-reader support for VoiceOver and TalkBack — ask any bidder, us included, for current conformance evidence rather than an intention.

07Data protection and security

Hosting inside the EU — Amazon Web Services, Ireland — on ISO/IEC 27001-certified infrastructure.
Role-based access control to systems, applications and information, with enforced password complexity and credentials never stored in readable form.
Account suspension after repeated failed login attempts, to prevent brute-force attacks.
Explicit acceptance of terms and privacy policy at registration, in both the app and the dashboard.
A privacy policy editable per project, so the authority can issue a version aligned with local data protection regulation.
No international data transfers without the prior authorisation of the data controller.

08Integrations

An open, documented REST API, with third-party authentication through standard JWT tokens (RFC 7519) issued by a dedicated endpoint after credentials are exchanged securely.
A webhook system, so third-party systems are notified when platform events occur — a vehicle arriving at a pickup point, for example — instead of polling the API.
A MaaS API allowing the authority's own application to show availability and manage the entire booking transaction, mirroring the supplier's passenger app, as part of a wider multimodal journey.
Payment through a gateway chosen by the operator or authority and configurable per service area, with the supplier acting strictly as a bridge and never holding passenger funds.
Exposure of the data needed to integrate a ticketing system — users, fares and pricing, zones, stops and areas — with integration to an existing fare-collection or validation scheme scoped once that system is identified.
Planned disruptions integrated into cartography and routing, so affected streets are accounted for when routes are calculated.
Trip-level operational and historical data — origin, destination, request time, request channel, payment status, delays, waiting and on-board times — available on request, as scheduled reports, and in the dashboard.
Export to the operator's data warehouse or BI tools through the API, or by scheduled FTP delivery as an alternative.

Specify this, not that

Where DRT tenders accidentally narrow the field

Six patterns we see repeatedly. Each one either locks an authority into one supplier or rules out the service model it actually wanted.

Instead of“The system shall use algorithm X for vehicle assignment.”RequireOutcome targets: maximum waiting time, maximum detour, minimum coverage of the service area.Naming a method rules out better ones and is unverifiable at evaluation. Targets can be measured in operation and enforced in the contract.
Instead of“Bidders shall supply in-vehicle tablets and mounts.”RequireCompatibility with standard Android and iOS devices, with hardware supply as a priced option.Bundling hardware inflates the bid and ties the fleet to one supplier's replacement cycle. Ask for it separately if you want it.
Instead of“The service shall operate between defined stops.”RequireSupport for stop-based, virtual-stop and door-to-door operation, configurable per area.A stops-only clause quietly excludes the door-to-door model that accessible and rural services usually need later.
Instead of“The supplier shall provide reports on request.”RequireTrip-level data ownership by the authority, with scheduled export by API or FTP, and full history on exit.Reports are a screenshot; data is an asset. Without an export clause the authority cannot evaluate the next tender.
Instead of“The system shall integrate with our ticketing.”RequireA documented API exposing users, fares, zones and stops, plus a named integration scope agreed after award.Undefined integration is where budgets disappear. Require the interface to exist; scope the specific connection separately.
Instead of“The passenger app shall be accessible.”RequireWCAG 2.1 AA conformance, native screen-reader support, and an accessibility flag at booking time.“Accessible” is not testable. These three are, and a supplier either meets them or does not.

Service models

Name the flexibility you want, not the vehicle you imagine

Demand-responsive transport is a ladder, not a single product. Most tenders name one rung and get stuck on it. Specify the rung you need per zone — and require that moving between rungs is a configuration change, not a new project.

Least flexibleFixed routeThe vehicle follows a predefined route, like a conventional line.When a recognisable public line must be preserved.
Rung twoFlexible routeA general corridor is kept, with permitted deviations to pick up or drop off nearby.Predictable, but reaches beyond the line.
Rung threeFeederThe service connects to a station, terminal or interchange rather than a destination.First and last mile onto the trunk network.
Rung fourCorner to cornerVirtual stops or meeting points close to origin and destination, assigned by the system.Balances convenience against pooling efficiency.
Most flexibleDoor to doorPickup and drop-off at specific addresses inside the authorised area.Villages, low density, reduced mobility.

Different rungs can run in the same deployment, one per zone — virtual stops in the dense centre, door-to-door in the villages, a flexible corridor along the trunk route. Ask bidders to demonstrate switching a zone from one model to another from the control panel, with the previous period's history still intact and separately reportable. It is the single fastest way to tell a configurable platform from a bespoke build.

Parameters and thresholds

The numbers a DRT tender should state

These are the values that decide whether a service feels reliable or arbitrary. Left unstated, each bidder assumes its own — and the bids become incomparable. Example values are what we see working in practice, not a recommendation for your area.

Maximum waiting time: 15 min; How long a passenger may wait between requesting and being collected. The single strongest driver of perceived reliability.
Maximum detour: +30%; How far a journey may be extended to pool another passenger. Sets the trade-off between efficiency and patience.
Vehicle capacity: 8 pax; Seats available per vehicle, and how many of those are wheelchair positions.
Accessibility priority: Priority; Whether wheelchair bookings are handled with priority, and against which service level.
Minimum transfer time: 5 min; The buffer kept when feeding a train or bus, so a delayed connection is not missed.
Recalculation response: < 5 s; How quickly the system must re-optimise after a parameter change or new request during a live demonstration.
Disruption recovery: < 60 s; How quickly passengers must be reallocated when a vehicle fails mid-shift.
Operating window: 06:00–22:00; Service hours per zone, per weekday and per request type, plus holiday exceptions.

Who owns which requirement

A single tender often covers timetabling, ticketing and on-demand operation at once. Requirements land on different systems, and a bidder answering for all of them is either a consortium or overstating. Say which is which.

The on-demand platform: Service areas and virtual stops, operational parameters, vehicle assignment and pooling, driver guidance, live supervision, on-demand KPIs, passenger app and notifications.
The planning and timetabling system: Line numbering and naming, timetable status and approval, running-time editing, journey blocks, departure-time comparison between lines, official stop attributes.
The authority itself: Cost data for cost-per-passenger analysis, the service level to be met, fare policy and the payment provider, the privacy policy issued to passengers, and which KPIs are contractual.

Get the checklist with the split already made →

Interoperability and data ownership

The clauses that decide whether you can leave

A DRT platform sits between your ticketing, your journey planner, your customer service and your reporting. If the tender does not name those seams, the winning bidder defines them — and the authority discovers the cost of exit years later.

These are the commitments we make, written as requirements you can impose on any bidder.

Open, documented API: Public technical documentation, shareable with the authority's integration team before award rather than after.
Webhooks instead of polling: Third-party systems are notified when events occur, so passenger information screens and CRM stay current without hammering the API.
The authority's own app can do everything: A dedicated MaaS API lets a third-party application show availability and manage the complete booking transaction, including payment where it handles payment itself.
Payments stay with the operator's provider: The operator or authority selects the payment provider, configurable per service area. Shotl acts as a bridge and never collects or holds passenger funds.
Data belongs to the authority and operator: As data owners they can request operational and historical data at any time, or receive scheduled reports — typically weekly — for automatic consumption.
Exit is a clause, not a negotiation: Trip-level history exports through the API or scheduled FTP into the operator's own warehouse or BI tools.
Disruptions enter the routing, not a phone call: Planned works and closures are integrated into cartography so routes account for them before a driver meets them.

For your data protection officer

What the privacy annex covers

Infrastructure is hosted on Amazon Web Services in Ireland, inside the EU, on ISO/IEC 27001-certified infrastructure. Role-based access control, enforced password complexity, credentials never stored in readable form, and account suspension after repeated failed logins.

The policy itself is adapted per project, so the authority and the operator can issue a version aligned with local regulation. No international transfers take place without the data controller's prior authorisation.

The corporate policies behind the product — environmental, code of ethics, anti-bribery, code of conduct — are stated on sustainability and ethics and available as signed documents.

Addressed in the default policy

Identification of the data controller and the data processor
Categories of data collected — identifiers, location, booking history, usage preferences — and whether each is mandatory or optional
The purposes of processing and the legal basis for each
The conditions under which data may be shared with public authorities or other providers involved in the service
Retention periods
User rights: access, rectification, erasure, restriction, portability and withdrawal of consent
The position on international transfers, which require the controller's prior authorisation

Current limits

What the platform does not do today

Stated here rather than discovered during evaluation. If any of these is decisive for your service, say so in the tender and we will answer it directly.

On the roadmapNo free-text driver messaging to the control centreRoute deviations are registered and re-optimised automatically, but a driver cannot yet send a written note or incident description into the dashboard. That conversation happens by phone or radio today. If it is decisive for your operation, say so and it can be prioritised for the project.
By designBookings are not edited in placeChanging a pickup time or destination means cancelling and recreating the trip from the dashboard. This is deliberate: every modified journey is then re-evaluated against current operational conditions rather than inheriting an obsolete plan.