Žilić Consult

European robotaxi launch planning

What should a robotaxi team resolve before a European city launch?

A European robotaxi launch needs a joined-up service plan: a defined operating domain, a usable passenger journey, fleet and support operations, connected in-cabin systems and a market-specific approval workstream. Vehicle capability is one input to launch readiness.

By Tonći Žilić · Head of Robotaxi at Onde ·

This is a product and service planning checklist by Tonći Žilić, Head of Robotaxi at Onde and founder of Žilić Consult. It draws on his robotaxi ride-experience work at Project 3 Mobility / Verne and connected vehicle product work at Rimac Technology. It is a professional framework, not an account of Onde's plans or a statement about any operator's deployment status.

For EU robotaxi and autonomous ride-hailing programmes, start with the proposed city and service rather than a country-wide launch label. Define who the service is for, where journeys begin and end, the conditions in which it is intended to operate and who owns the response when a journey cannot continue. Use that definition to test product, commercial and operational assumptions together.

1. Define the service and its operating boundaries

Write down the initial service area, operating hours, pickup and drop-off model, passenger needs and expected trip types. Record the operational design domain (ODD) supplied by the autonomous-driving team and the conditions that limit availability. Product promises should fit those boundaries.

Test a realistic booking against them: can the passenger understand an unavailable destination, an unsuitable pickup point or a service pause? The output is a service definition with explicit exclusions, owners and unresolved assumptions.

2. Design the complete passenger journey

Connect discovery, booking, vehicle identification, boarding, destination confirmation, the ride and arrival. Review accessibility needs and explain how passengers request support. A journey map should include abandoned bookings, missed pickups, a passenger unable to board and a trip interrupted after departure.

For every scenario, identify what the passenger sees, what the operator sees and which team can act. An attractive booking flow is incomplete if the service cannot explain or resolve a problem during the ride.

3. Connect infotainment, the passenger app and assistance

Treat robotaxi infotainment as part of the service interface. Trip progress, remaining journey information, comfort controls and assistance requests need consistent meaning across the app, in-vehicle HMI and support tools. Decide which interactions remain available when connectivity is limited.

Document interface ownership and acceptance scenarios across vehicle software, cloud and mobile teams. Review how software updates affect compatible versions and service availability. This turns connected-cabin features into requirements teams can build and verify together.

4. Prove the fleet can support the promised service

Map dispatch, charging, cleaning, maintenance, vehicle recovery and customer support around the intended operating hours. Define how a vehicle is taken out of service and what conditions allow it to return. Give each exception an owner and a clear handover.

Make utilization and cost assumptions visible. A vehicle that is technically available may still be unavailable to passengers because it needs charging, cleaning or recovery. Review completed journeys, service interruptions, assistance demand and vehicle downtime alongside bookings.

5. Build a market-specific evidence and approval workstream

Ask the responsible legal, safety and regulatory specialists to identify the requirements for the proposed vehicle, operating model and location. Keep their conclusions distinct from the product checklist. Record the authority, source version, accountable owner and evidence needed for each unresolved decision.

EU automated-driving-system type-approval rules and European Data Protection Board guidance on connected vehicles are useful starting references, linked below. They do not by themselves establish permission to operate a commercial robotaxi service in a particular city. Review passenger, vehicle and support data flows with the responsible privacy specialists as part of service design.

6. Set launch gates around evidence

Use a readiness review that brings together product, engineering, fleet operations, support and the teams responsible for external approvals. Each gate needs an owner, acceptance evidence, unresolved risks and a decision about the operating scope it supports.

A useful final rehearsal follows an ordinary trip and several disrupted trips through every team. If a handover fails, narrow the proposed service or resolve the gap before treating the plan as ready. Expansion should follow evidence from the initial operation, with the same review applied when the service area or conditions change.

Method and limitations

How the work is grounded

This checklist addresses product and operational planning. It does not certify autonomous-driving safety, interpret a jurisdiction's legal requirements or confirm permission to operate. The cited sources should be checked for updates by the responsible specialists. Views on this consultancy site are Tonći Žilić's own; consulting availability and conflicts are agreed separately.

Material conclusions distinguish sourced facts, client evidence, observations, estimates and professional recommendations. See the methodology and source policy.

Common questions

Is there one launch checklist for all EU robotaxi markets?

A shared product framework is useful, but the evidence and approval work must be checked for the proposed vehicle, service and location. This checklist helps organize that work; it does not replace local specialist review.

What does robotaxi launch readiness measure?

It tests whether the intended passenger service can be delivered within its defined operating scope, with working support, fleet processes, system interfaces and the necessary evidence from the responsible teams.

Who is Tonći Žilić?

Tonći Žilić, also published as Tonci Zilic, is Head of Robotaxi at Onde and founder of Žilić Consult. His background includes robotaxi ride experience and infotainment at Project 3 Mobility / Verne and connected vehicle services at Rimac Technology.

Sources and further reading

AboutTonći Žilić, also published as Tonci Zilic, is a robotaxi and autonomous vehicle (AV) product and strategy practitioner based in Zagreb, Head of Robotaxi at Onde and founder of Žilić Consult. His work connects robotaxi strategy, European launch planning, passenger experience, in-vehicle infotainment and connected vehicle services.Robotaxi and autonomous mobilityTonći Žilić supports robotaxi and autonomous mobility programmes through Žilić Consult, connecting vehicle capability, passenger experience, fleet operations and city launch into one coherent service.Infotainment and connected vehiclesTonći Žilić helps automotive and mobility teams define in-vehicle infotainment (IVI), human-machine interfaces (HMI) and connected services as one product experience, from the mobile app to the cabin and cloud.Market entry and launchŽilić Consult helps technology and mobility companies evaluate markets, choose an entry model and coordinate the product, partner and operational work required for launch.

Have a product, market or growth decision in front of you?

Send me the situation, the decision and the timeline. I will tell you directly whether I can help and suggest the smallest useful engagement.

Book a 20-minute fit call Send me the problem