Skip to content

Implementation roadmap

From signed contract to first passenger

What actually happens after the tender is won. No new infrastructure is required — the work is service design, configuration and people. Most deployments carry these six phases; a simple service can move through them in weeks.

A student with a backpack checks the on-demand service on her phone by a stone wall
  1. 01

    Service design, together

    Before anything is configured we design the service with you: the area, the stops or door-to-door zones, operating hours per vehicle and weekday, fares if any, and the promises made to passengers. A free simulation models the options so decisions rest on evidence, not assumptions — including the minimum fleet the demand actually needs.

    Typically settled here

    • Service area, subareas and stop network
    • Fleet size, from simulation
    • Waiting-time and detour targets
    • Operating hours and exceptions
  2. 02

    Listening on the ground

    Every operation starts with the people who will use it. The pattern we follow: initial meetings with the town hall or authority, calls with local experts, focus groups with potential riders, interviews with end users, and a visit to see the area first-hand. This is where phone booking, accessibility needs and real travel patterns surface.

    The Ongar Academy lesson

    • Focus groups changed the service design
    • Parents needed app-based cancellation
    • The site visit caught what data missed
  3. 03

    Configuration, not construction

    The platform is configured for your service: zones and virtual stops, vehicles and shifts, prohibited streets, languages, branding on the white-label apps, and the legal texts your DPO signs off. No hardware is installed unless you want it — drivers can run on standard phones or tablets.

    Configured in this phase

    • Apps in your brand and languages
    • Roles and permissions for your staff
    • Street rules and holiday exceptions
    • Privacy policy adapted to local law
  4. 04

    Training the people who run it

    Dispatchers learn the dashboard; drivers learn the driver app on their own vehicles. The aim is that on day one, nobody is operating software they saw for the first time that morning.

    Who gets trained

    • Controllers and dispatchers
    • Drivers, on route and in vehicle
  5. 05

    Go-live, gradually

    Services usually start with the existing timetable behaviour and open flexibility progressively — a school service can run its first days as a plain on-demand operation before pre-programmed school runs switch on. A launch is an event for the newsroom, but operationally it should feel boring.

    First weeks

    • Soft start with existing patterns
    • Daily monitoring with our team
    • Passenger communication support
  6. 06

    Optimise on evidence

    The service is watched and tuned: stops added where demand shows (Maresme added one within two months), hours adjusted, modes switched by configuration. Weekly trip-level data flows to your BI, and the numbers that defend the service at budget time accumulate from day one.

    Continuously

    • KPI reporting, scheduled or on request
    • Stops and zones adjusted from demand data
    • Quarterly service reviews

What you bring

  • Vehicles and drivers (yours or your operator's)
  • Knowledge of the area
  • The service rules that matter politically — hours, fares, who rides
  • A contact who can decide
  • Honesty about what the current service costs

What we bring

  • The platform configured for your area
  • The simulation that sizes it
  • Passenger, driver and dashboard apps in your languages and brand
  • Training for dispatchers and drivers
  • Mobility experts who have launched services in towns like yours and stay through the first months

Still specifying, not implementing?

The RFP resources carry the requirement wording and platform facts; the guides include the editable specification and acceptance tests.