A chauffeur-driven car on demand to avoid owning one when our usage doesn’t justify it. An additional means to bridge the gap between two modes of transportation when distance, available service hours, or other reasons prevent walking or cycling. Plenty of reasons to justify the presence of taxis among the essential modes of transportation for sustainable mobility in Greater Montreal.
How did the experimentation facilitate the integration of this complex and diverse industry into innovation dynamics while staying close to the concerns of its users and the industry? How did the question of taxi data valorization gradually shift efforts and reflections towards better connection with the field?
This article traces the trajectory of the integration project of the Taxi Registry into a route planner and the experiments that helped identify its key elements, as La Fabrique des Mobilités Québec contributes to unlocking the challenges raised by stakeholders. We published a first article this winter about the current state of the taxi industry and its evolution to begin sharing the learnings.
How to integrate taxis into integrated mobility?
For several years, the Montreal Taxi Bureau (BTM) and professionals from the City of Montreal’s Information Technology Service have maintained and developed the “Taxi Registry.” This registry is a map that allows real-time visualization of the geolocated position of each taxi and information about its availability.
As the registry was quickly seen as an opportunity to share taxi data that would be useful to the mobility ecosystem, the teams involved then worked on open data standards (“GOFS” renamed to “GTFS-on Demand, subsequently leading to the idea of integrating this registry into a route planner. At the beginning of Montreal en commun, the goal was to validate this integration as a “proof of concept.”1
La Fabrique des Mobilités mainly intervened in two areas of experimentation: technical (testing API2 functionality, user experience testing) and stakeholder engagement (surveying operators, gathering user needs, and comparing existing planning solutions on the market).
De-risking through experimentation, maximizing chances of success in the market
Initially, La Fabrique des Mobilités was approached to work on taxi data use cases on one hand and a comparison of planning solutions on the market on the other, centered around the business models of various possible providers, with their advantages and disadvantages. This highlighted the planner best suited to the needs of the BTM.
However, since this result involved subsequent negotiation work, La Fabrique des Mobilités Québec was able to propose the opportunity to de-risk the operation of the Registry’s API key upstream to facilitate its integration (or that of the format best suited to the chosen application). This proposal offered a double advantage: enriching the route planning tool (based on Open Trip Planner) and verifying the proper functioning of the Registry on the other (especially in the equitable distribution between taxi operators). This experimentation, carried out with the City’s IT service and the BTM, followed the integration of the Registry and allowed the teams’ years of work to materialize and be valued as a success.
Subsequent reflections on these tests also helped identify and address some reservations from taxi operators, essential stakeholders in the smooth functioning of adding this mode of transportation to the future “integrated mobility” project. Some expressed doubts about the fairness of such technology in taxi solicitation via the Registry and the distribution of customers among operators.
These questions led to the second axis of experimental work: understanding the needs and issues of operators and users. For this, we conducted two surveys: the first, aimed at operators to understand their familiarity with the user journeys of their users, and the second, to gauge the expectations of the users themselves. These two “mirror” surveys were supposed to help us identify possible misalignments or blind spots in the development of solutions like integrating the Registry into a planner.
The well-established climate of trust will allow a live test with the BTM to validate the proper functioning of the API, finally dispelling the doubts present at the start in the coming months.
Today, we are working to better map our knowledge of user journeys around the Registry to identify priority risks for upcoming experiments. For example, the issue of transitioning from one interface (planner) to another (operator) and potential associated user experience problems seem to emerge as elements to de-risk soon. This understanding of needs also helps to work on the positioning of taxis within integrated mobility options, particularly how to differentiate them from Uber and highlight their unique value.
- “A proof of concept (which we’ll call POC for Proof of Concept) is a demonstration of feasibility, i.e. a concrete and preliminary experimental realization, short or incomplete, illustrating a certain method or idea in order to demonstrate or not its feasibility”.(Source) ↩︎
- Application Programming Interface: an API is a “software interface that enables one software program or service to be ‘connected’ to another software program or service in order to exchange data and functionality.”(Source) ↩︎