Multimodal bookings
One journey, however many vehicles it takes
Riders don't plan legs, they plan trips. Your on-demand service belongs inside the planner, the app and the ticket they already use.
Does this sound familiar?
Four problems network planners keep running into
Good services that riders can’t connect to — these four come up in almost every first conversation. Each one has the same answer.
- 01“Riders don’t know we exist”Riders plan whole journeys in one app, and a service missing from that app is a service they never consider.Appear next to the trains and the trams
- 02“It’s two apps and two tickets”Every extra download and separate fare is friction the car does not have.Book and pay where the rider already is
- 03“The connection is always missed”On an hourly rural service, a five-minute slip is an hour lost — and one bad experience ends the habit.Treat the interchange as a promise, not a coincidence
- 04“The tender asks for open integration”Open data, platform integration and exportable operations data are scored requirements in most tenders now.Answer the integration clause with documentation
The answer
Get every rider to the train, tram or bus they need
Connect an on-demand leg to the trains, trams and buses riders already use, so they plan and book one journey instead of two. That is multimodal bookings.
Set it up your way
- Show the whole journey, end to endLet riders book the on-demand leg while seeing the whole trip, including the stop and departure they connect to.
- Protect every connectionSet a buffer between the two legs, so a small delay never costs the rider the onward train.
- Appear in the apps riders already useList the service next to the trains and trams, instead of in a separate app of its own.
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
What makes a service intermodal?
The rider treats several modes as one trip. In practice that means the flexible leg is published to journey planners, can be booked and paid inside the region's app or fare system, and its interchange times are guaranteed rather than hoped for.
Do we need our own app?
No. Shotl services can run white-label under your brand, appear inside regional MaaS and journey-planner apps, or both at once — the operations behind the trip are the same.
Which standards and integrations are supported?
GTFS and GTFS-realtime feeds in and out, documented booking and payment APIs, deep links and single sign-on, plus data exports for BI and open-data obligations. See the API and Integrations page for detail.
How long does an integration take?
A typical MaaS or journey-planner integration takes about two weeks from requirement to live, because the feeds and APIs already exist rather than being built per client.
How are missed connections avoided?
Interchange windows are configured per service and enforced when trips are assigned. If a pooling option would put the connection at risk, the engine does not take it, and operations are alerted while the trip can still be recovered.
