Mobility as a Service (MaaS) Planning and Implementation: Challenges and Lessons Learned

Abstract

Mobility as a Service (MaaS) is an innovative mobility service that aims to redesign the future of urban mobility by integrating multi-modal transportation and app-based technologies to enable seamless urban mobility. While MaaS pilot demonstrations and schemes implementation have taken place in different cities at a global level, and relevant studies focus on the MaaS barriers and users’ characteristics, the planning process for implementing MaaS is rarely presented. This paper summarizes the services to be integrated into the MaaS Athens’ demo site in Greece and describes the planning process that was followed to showcase the demo. The demo site is located within the urban area of Athens, including a public transport operator, a bike-sharing service, a taxi operator, and a municipality public transport operator. The demonstration runs developments in a real corridor that has the potential to prepare the MaaS eco-system deployment and market uptake. Three travel cases are planned: (1) Multimodal work trip; (2) MaaS for tourists; and (3) Interurban/urban interfaces, for work and shopping/leisure trips. The user journeys are defined in detail and the main information for each user journey is presented. The study concludes with challenges that were faced during the demo planning and recommendations for achieving the MaaS goals.

1. Introduction

Τhe Mobility-as-a-Service (MaaS) concept has been developed within the past ten years and integrates public and private mobility modes to promote on-demand mobility [1,2]. The International Association for Public Transport Authorities (UITP) defines MaaS [3]: “MaaS is the integration of, and access to, different transport services (such as public transport, ride-sharing, car-sharing, bike-sharing, scooter-sharing, taxi, car rental, ride-hailing and so on) in one single digital mobility offer, with active mobility and an efficient public transport system as its basis. This tailormade service suggests the most suitable solutions based on the user’s travel needs. MaaS is available anytime and offers integrated planning, booking and payment, as well as en route information to provide easy mobility and enable life without having to own a car”.

Recent studies have highlighted the role of MaaS in increasing efficiency both for mobility systems and individual users [4]. MaaS aims to redesign the future of urban mobility by integrating multi-modal transportation with Information and Communications Technologies (ICT) and app-based technologies [5,6]. MaaS provides a more convenient and more sustainable solution than owning and driving private cars, which subsequently leads to the reduction of congestion in city centers and suburbs, the reduction of traffic accidents, and the reduction of required space for parking [7]. The assumption that supports MaaS is that a seamless integration of a wide range of mobility services, such as bike-sharing with public transportation services, or carpooling with public transport [8], is more appealing than owning, maintaining, and operating a private vehicle [4,7].

Despite the fact that several MaaS solutions have been developed lately at the global level, the MaaS concept has its roots in the Nordic nations. It is claimed that Heikkilä coined the term in 2014 [9]; her thesis resulted in a call for pilot projects from the Finnish Innovation Agency and led to the founding of the first MaaS company in 2015, named MaaS Global [2]. They developed the Whim app that operated in Finland, Austria, Belgium, Japan, and the UK [7]. Moreover, around the same time in Sweden, a MaaS trial known as Go:Smart (later renamed UbiGo) was financed by the Swedish Innovation Agency to develop, test, and evaluate ways of offering a mobility solution for sustainable traveling in the city of Gothenburg. UbiGo was launched in Stockholm in 2019 but ceased operation in early 2021 [7]. Although several pilots have been demonstrated and evaluated, only a small number of them resulted in a product in the market.

Towards this end, several studies have focused on barriers to implementing MaaS (e.g., [10,11,12]), however, the planning and implementation of a step-by-step process is not presented thoroughly. This paper aims to outline the planning process of a MaaS pilot in central Athens, the capital of Greece, and report the challenges that were faced during the preparation of the demonstration and the implementation phases. The methodology that was used for the planning process of the MaaS pilot is presented and provides guidance for future MaaS pilot schemes. Identified challenges are linked to lessons learned to provide recommendations for planning and implementing successful MaaS pilots. This research contributes to the expanding knowledge on MaaS for setting up demonstration sites by outlining a step-by-step planning and implementation method, and lessons learned to support involved MaaS stakeholders (i.e., researchers, public authorities, transport service providers and operators, etc.).

In the remainder of this paper, Section 2 provides a summary of literature findings on the MaaS concept and applications in pilots around the world and highlights literature limitations. The MaaS scheme of the study is presented as a step-by-step process in Section 3, including the description of the app, functionalities, planning for routes and modes, and demo deployment. The implementation phase is described in Section 4. Section 5 concludes with a discussion of identified challenges and lessons learned following the implementation of the MaaS.

2. Background

The MaaS provides the ability for travelers to combine public and private transport modes within a city or beyond by using a single application. A key success factor for the MaaS is the utilization of a reliable account to book and pay for used transport services [13]. MaaS is often referred to as a tool that could help increase the sustainability of transport systems [14,15,16,17]; however, a universal definition of MaaS has not yet been established [18].

2.1. MaaS Impacts

The anticipated MaaS benefits focus on the optimization of the existing public transport services within a city and the increase in travelers’ satisfaction [11]. MaaS may also improve network efficiency by optimizing supply and demand, especially during peak hours when certain modes/routes are under-utilized, and reduce traffic congestion, transport costs for end-users, and car ownership [11]. The implementation of MaaS may lead to emission reductions [19] and offers seamless end-to-end mobility to its users [20]. According to Kamargianni et al. [21], if Maas is structured and priced properly, it could provide benefits, including increased public transport ridership and active transport usage, and offer intermodal solutions [21] Soteropoulos et al. (2021) [22] mentioned MaaS as being one of the potential solutions for addressing the challenges of future mobility. They suggested that automated vehicles and MaaS could potentially reduce the need for private car ownership and provide more efficient and sustainable transportation options. Existing research indicates that MaaS contributes to reduced dependence on private vehicles [23], reduction of transport-related emissions [24], enhancement of transport system reliability [25], increased convenience and accessibility, reduced traffic congestion, and cost savings for users, increased flexibility for its users in the post-pandemic era [26], and new opportunities for innovation and new business models for involved stakeholders [27].

2.2. Planning and Implementation

The need to switch from single-mode planning to multimodality and build a resilient transport network has been also highlighted by the recent COVID-19 pandemic. The emphasis on resilience implies going beyond single-mode resilience to cross-modal, systemic resilience optimization [28]. However, there is a high degree of ambiguity surrounding the MaaS concept, planning, and implementation [29]. Following a critical literature review by Jittrapirom et al. [29] the identified core characteristics when implementing a MaaS are the integration of transport modes, tariff options, the platform, coordination of multiple actors, use of technologies, demand orientation, registration requirements, personalization, and customization.

MaaS has been studied in the literature both theoretically [14,30] and practically. At the practical level, MaaS has been tested either within the framework of research projects [31,32,33] or has been implemented in several urban areas (e.g., Ubigo and Whim app).

Table 1. Overview of MaaS Applications.

Application Name	Transport Modes	Demo Site	Study
Beeline	Bus services	Singapore	[31]
BIP for MaaS	Public transport, bike sharing, traditional, free floating and electric car sharing, and carpooling	Torino, Italy (EU)	[32]
Bridj	On-demand commuter shuttle service	Boston, Kansas City, and Washington, DC (US)	[31]
Communauto/Bixi	Bike sharing and car sharing	Quebec, Canada (US)	[31,33]
EMMA	Public transport system, Bike sharing system, car and bike parking services, car sharing,	Montpellier, France (EU)	[33,34]
Get me there	Bus, tram, metro, taxi, car-sharing, rail, coaches, electric vehicle charging infrastructure, and parking operators	Greater Manchester, North West England	[32]
Hannovermobil 2.0	Public transport, car sharing, and taxi	Hanover Region, Germany (EU)	[33,34,35]
Helsinki Model (Whim app)	Public transport, taxis, city bikes, car rental, car sharing, e-scooters, and shared bikes + on-demand transport	Helsinki and Turku, Finland (EU)	[9,31,33,34]
MaaS-London App	Car clubs (car sharing services), ride sharing, bike sharing, taxi and all types of public transport (London underground, overground, bus, tramlink, DLR, river bus, and national rail)	London (UK)	[34]
Mobility Shop	Public transport, bike sharing, car sharing, car rental, taxi, train	Helsinki, Finland (EU)	[4,36]
Moovel	Public transport, car sharing, car rental, national rail, bike sharing, and taxis	Germany (EU), also testing in Boston, Portland, and Helsinki	[4,31,33,34]
Qixxit	Car sharing, ride sharing, and bike sharing	Germany (EU)	[31]
SHIFT	Shuttle buses, bike sharing, car rental, car sharing, and valet service	Las Vegas (US)	[4,33,34]
SMILE App	Public transport, rail, car sharing, bike sharing, car rental, taxi	Vienna, Austria (EU)	[4,31,33,34]
TransitApp	Public transport, bike sharing, car sharing, taxi, ride-hailing	USA, UK, Canada, Europe, Australia	[4]
Ubigo	Public transport, car sharing, car rentals, bike sharing, taxi service, car-pool, and bike-pool	Gothenburg and Västra Region, Sweden (EU)	[4,10,31,32,33,37,38]
URBI mobility	Regional and city trains, subway, trams, buses, free-floating and stationary vehicle-sharing, scooter-sharing, bike-sharing, taxis, and Uber	Berlin Brandenburg metropolitan and regional area, Germany (EU)	[32]
WienMobil Lab	Public transport, bike sharing, car sharing, taxi, parking garages	Vienna, Austria (EU)	[4]

presents MaaS applications that have been tested or released in the market.

MaaS utilize apps that offer a monthly subscription or a pay-as-you-go service for a single or a group of travelers to combine transport modes and use them with a single payment [13]; different apps and platforms have been deployed to support local MaaS systems. MaaS Global released Whim, the first MaaS solution in the world [39]. Currently, Whim operates in Helsinki and Turku (Finland), Antwerpen (Belgium), Vienna (Austria), West Midlands (UK), multiple cities in Switzerland, and Greater Tokyo (Japan). The Whim is an award-winning mobility app that facilitates mobility by offering two types of MaaS service: purchasing a season ticket (predefined mobility packages), and a single trip ticket (pay-as-you-go). The season ticket includes unlimited usage of public transport, taxi, city bikes, car rental, e-scooters, and shared bikes. In Los Angeles and Denver (US), a mobility platform was launched in 2016 to assist residents and tourists make travel choices more easily [13]. The “Go Denver” and “Go LA” apps estimated different routes, including the greenest one, by considering individuals’ destinations and desired arrival time. The apps aggregated and calculated the time, cost, carbon footprint, and health benefits of walking, biking, driving, parking, public transit, and emerging ride-hailing options [40]. The UbiGo app in Gothenburg, Sweden [32,37,38] offers a monthly subscription for public transport, car sharing, car rentals, bike sharing, and taxi services [10].

At the moment, there are at least three ongoing MaaS initiatives in the city of Madrid, yet there is no collaboration among them. The main challenge that they face is also confirmed by literature findings: the lack of a governance framework for MaaS [41]. Given the different circumstances and conditions in different cities and regions, it seems unlikely that a single MaaS model would be universally applicable [42].

Boero et al. [32] described the MaaS concept and its implementation in the context of the IMOVE project. Furthermore, they described the organizational and technological enablers for MaaS and the main objectives and elements in the participating pilot sites. IMOVE was first implemented in four European areas (Living Labs) including Göteborg, the Västra Götaland region, the Berlin Brandenburg region, Greater Manchester, and Turin. The living labs combined several modes to deploy MaaS services, such as public transport, car-pool, bike-pool, taxi, U-Bahn (subway), tram, bus, free-floating and stationary vehicle-sharing, scooter-sharing, bike-sharing, and Uber.

2.3. Challenges and Barriers

Several stakeholders, including transportation planners, operators, and policy makers are interested in planning and implementing MaaS [11]. However, potential societal, operational, financial, and regulatory barriers might hinder the MaaS success as concluded in the literature [11]. For example, dependence on the MaaS to improve mobility and accessibility of individuals may create equity issues [43], which should be considered within the transport policy and practice field. Furthermore, without a supportive built environment and high-quality public transport system, MaaS will likely not succeed to change travelers’ behavior [28]. The degree these challenges are addressed affect the degree the potential benefits of MaaS are achieved [44].

EU-funded projects have recently demonstrated MaaS solutions in several cities (

Table 2. A sample of recent EU MaaS pilots.

Project	City Pilot	Year Tested	Major Challenges
[45]	Greater Manchester (UK)	2018	Business, end-users, technology, and policy challenges (i.e., rapid growth of new mobility solutions such as dockless cycling, and UK de-regulated market; participants do not fully understand the MaaS concept and there is confusion with Smart Ticketing, etc.)
	Luxembourg (LU)—Germany (DE)	2018	Business, end-users, technology, and policy challenges (i.e., The collaboration of private companies with public organizations in MaaS, people’s strong reliance on their private cars, and the need for some regulatory modifications.)
	Budapest (HU)	2018	Τhe ticketing system of the public transport authority does not accept mobile-based ticketing solutions.
[46]	Amsterdam (NL)	2019	The integration of a big number of mobility services in order to provide an attractive and ideally all-encompassing service.
	Athens & Korinthos (GR)	2019
	Rome (IT)	2019	The provision of the most up-to-date traffic information and guidance to users regarding the best route to avoid unexpected events and congested roads.
	Prague (CZ)	2019	-
	Salzburg (AT)	2019	The integration of a big number of mobility services in order to provide an attractive and ideally all-encompassing service.
[27]	Lisbon (PT)	2021	Ticketing, lack of an interoperability framework, and scalability to sustain a large deployment. Need to simplify/automate all the necessary steps to integrate new services and sub-systems in the IP4 ecosystem. Public/private mobility integration, information handling and sharing, service interoperability, and scalability requirements
	Malaga (ES)	2021
	Central east corridor (Berlin (DE) and Brno (CZ))	2021
[47]	Barcelona (ES)	2023	In progress
	Athens (GR)	2022	2nd phase in progress (Challenges are outlined in Section 4)
	Warsaw (PL)	2023	In progress
	Osijek (HR)	2023	In progress
	Liberec (CZ)	2023	In progress
	Padua (IT)	2023	In progress

), yet the challenges that they faced during the implementation process are mainly technological integration of different Transport Service Provider (TSP) platforms and institutional issues. Table 2 presents a summary of recently demonstrated pilots in EU projects and the main challenges they faced during testing.

The MaaS4EU project concluded that major legal and regulatory barriers exist for the implementation of MaaS services [45] that make participating in a MaaS scheme difficult for suppliers and public service providers. The project stresses that regulations and passenger rights can largely differ across different modes, due to the lack of a unimodal approach in the EU legislative framework. The MyCorridor project [46] categorized barriers as well as enablers into five categories: User and market, Technology, Organization, Business, and Legal. However, legal issues for MaaS implementation were emphasized by further grouping them into: data protection, cybersecurity, intellectual agreements, consumer and payment laws, data interoperability, and local regulations. One of the latest MaaS demonstrations, within the framework of the Shift2Maas project [27] highlighted challenges related to regulations, including data privacy (GDPR) as well as the local variation of regulations. Shift2MaaS proposed a roadmap, summarizing recommendations based on three pillars: regulation, business models, and technical issues. The IP4MaaS project extracts information and lessons learned from the MyCorridor and Shift2MaaS projects to build use cases and plan its demonstration.

Except for major challenges that interested stakeholders may face during MaaS implementation, barriers may also exist on the users’ side. Sochor et al. [10] conducted a six-month field test in Gothenburg, Sweden to explore motivations and barriers to adopting new travel services. Potential users were initially motivated by curiosity, convenience, and fare savings. Results showed that is vital to generate interest and excitement in potential users regarding a new transportation scheme. Users provided positive feedback, but service providers faced regulatory and institutional barriers [37]. Reasons for users not joining Ubigo included fare affordability (i.e., more expensive than the existing transport solution), a perceived mismatch between the user and the service, and lack of infrastructure (e.g., bike-sharing or car-sharing stations) to serve new users [10].

The substantial barriers to implementing MaaS were also identified and grouped into categories for two European metropolitan areas, Budapest (Hungary) and Manchester (UK) [11];

Table 3. Main barriers to implementing MaaS [11].

Barrier Category	Barriers
	Greater Manchester (UK)	Budapest (HU)
Institutional/ Regulatory	Monopoly in the long term	Political opposition
	Needs business reorganization	Needs business reorganization
	Unwillingness of cooperation among TSPs and the MaaS operator	Unwillingness of cooperation among TSPs and the MaaS operator
	-	Monopoly in the long term
Social	Strong reliance of people on private cars	Strong reliance of people on private cars
Financial	Viability of business model	Regulatory risks
	Macroeconomic risks	Viability of business model
	Partnership risks	Partnership risks
	Innovation risks	Non-credit rated activity
Operational/ Technical	Limited availability of APIs	Unwillingness to share data
	Unwillingness to share data	Standardization of data among TSPs and data providers
	Standardization of data among TSPs and data providers	Low ICT availability to support MaaS
	“Unbanked” travelers that may not be able to access MaaS services	-

presents the main ones.

The following sections describe the step-by-step planning and implementation process of the MaaS pilot in Athens, Greece to provide a guideline for interested stakeholders and investigate whether literature findings regarding MaaS implementation challenges are applicable in this case.

3. The MaaS Scheme

The IP4MaaS project aims to advance the uptake of Mobility as a Service (MaaS) schemes by analyzing and testing technologies developed under the Innovation Programme 4 (IP4) of the Shift2Rail Joint Undertaking. The work conducted within the Shift2Rail framework is structured, first of all, around five asset-specific Innovation Programmes (IPs), covering the different structural (technical) and functional (process) subsystems of the rail system. Within the IP4, the rail aims to develop Information Technology (IT) solutions to become a more attractive option, to respond to customer needs to support door-to-door, intermodal journeys.

Within the framework of IP4MaaS, a panel of demo sites is deployed, to facilitate and coordinate the demonstration of MaaS technologies and offer seamless experiences of multimodal traveling. The project deploys six MaaS demonstrations in diverse urban or/and interurban contexts, all addressing cases of commuters, tourists, and other users who were attracted to public and shared transport services.

3.1. Demo Area

The Athens demo focuses on enhancing multimodality by providing journey planning and integrated ticketing through a single application. Journey planners combine several transport modes, including public and personal transport such as private cars, bikes, and walking. Although an extensive list of personal transport modes is not included within journey planners, mode-specific considerations are performed on the basis of available infrastructure (i.e., public transport lanes, bike, and pedestrian routes, and car routes). The journey planner that is demonstrated herein considers public transport, bike, pedestrian, and car routings to provide optimal means of traveling. Travelers may use other transport modes (e.g., electric skateboards, e-scooters, etc.) in the suggested routings by considering the regulations and traffic conditions of the region. The demo site is located within the urban area of Athens, including also a small Public Transport Operator (PTO), the Municipality of Iraklio (MIRAKLIO). The municipality is located 8.5 km from central Athens and directly provides PT services in its territory (Figure 1).

Attica is Greece’s region with the highest inhabitancy rate, including the country’s capital city, Athens [48]. The Region of Attica covers an area of 3808 km², is home to a population of about 3,923,000, and is divided administratively into 113 Municipalities, while the municipality of Athens due to its large size is subdivided into seven districts [49]. Attica’s public transport network consists of five different public transport modes: metro, suburban railway, tramway line, buses, and trolleybuses, which are run by different operators [50]. The Athens Metro network is composed of three lines with 67 stations, and a total length of 85.3 km, transferring around 1,400,000 passengers/day [51]. Line 1 commenced its operation in 1869, and lines 2 and 3 in 2000 with subsequent system extensions in 2004, 2007, 2009, 2010, 2013, and 2021 with a total of 39 new underground metro stations [50,52]. All three lines pass through the center of Athens, with several interchanges between them [50]. The suburban railway which commenced its operation in 2004, is 20.7 km long and connects the Athens International Airport with the city center of Athens and the port of Piraeus [50,53]. The tramway line links the center of Athens with the port of Piraeus, Faliro, a south area next to Piraeus, and the southern suburb of Voula. The tram started its operation in 2004 and runs on a 31.3 km long network [50,51]. Finally, there is an extensive bus and trolley network, consisting of about 260 bus routes and 19 trolley routes, covering most of the Athens metropolitan area [50].

Currently, the Public Urban Transport Organization of Athens (OASA) provides a reloadable card (i.e., ATH.ENA card), which may be topped up with multiple fare products depending on trip needs and affordability. This card can be used in all transport modes and operators belonging to the OASA network, namely buses, trams, trolleys, and metro (3 lines). The OASA telematics app allows the user to plan a journey using the metro and the tram starting and ending at two different stations, hence not covering the door-to-door part. The app also provides information about the exact time of the vehicle’s (bus) arrival at the bus stop and the vehicle’s position on the network. Alternatively, through Google Transit, a user can plan a journey using all modes of public transport and potential walking parts.

To further expand the use of ATH.ENA card within the demo, the OASA established cooperation with a taxi company and a bike-sharing service. In this way, travelers that need to use a taxi or a bike for the first and/or final part of their trip, may use the developed app to hail them.

The demonstration runs the proposed developments in a real corridor that has the potential to prepare the MaaS eco-system deployment and market uptake. The rationale for the corridor selection lies in the existence of multimodal transport for people on a daily basis and the lack of an optimal scheme of connections between them to improve the overall performance of the transportation system. Bike-sharing and ride-sharing with taxis have limited application in the area but they are the main drivers for new services provision at the level of the municipality and the wider agglomeration.

3.2. App Description

The digital medium to access the bundle of available mobility services in the Athens demo is a single MaaS mobile application for Android, namely the Travel Companion (TC). The TC is a global application, so the travelers will use the same mobile app when they are in Athens or any other IP4MaaS pilot site. The TC is meant to be used by registered users; following registration, the user has to log in to access digital services.

When entering the TC app, the traveler has two options to purchase a mobility service:

• Purchase a mobility package. In this case, the travel products have been registered beforehand by the Travel Service Providers (TSPs).
• Request a journey by entering the origin/destination and preferred time of departure or/and arrival. The TC app returns a list of possible journeys and alternative transport modes or a combination of modes. An example of this sequence of actions is presented in the app screenshots (Figure 2).

The traveler has a variety of actions available at this stage, called the shopping stage. They may start navigation, share a particular trip with another user, or investigate the possibility to share a trip with other travelers. Most importantly, the traveler is able to book a trip or a leg of a trip upon availability and purchase a ticket. For the needs of the MaaS pilot, when the financial transaction is completed a digital ticket (i.e., a QR code ticket) suitable for the selected trip is downloaded on the TC app, and the traveler uses it for traveling. The planning, booking, and ticketing procedures are the cornerstone of the MaaS service; thus, they require a great amount of integration with existing local TSP systems.

Finally, during the traveling phase, the user may access a set of functions within the TC, such as travel alerts, messages, and location-based experiences (i.e., infotainment features). All itineraries are organized within the TC and the traveler may review and amend them. The TC keeps the traveler always informed, entertained, and in control of their travel, both during the pre-trip and on-trip phases, regardless if the trip is considered intermodal or a single-mode trip. The provision of real-time information was not available in the phase of the demo, due to a lack of integration between operational systems and the app, which is considered a drawback in proving the real potential of the MaaS scheme.

3.3. App Functionalities

The main focus of the Athens demo is to introduce “mobility packages”, i.e., a combination of fare products by various TSPs bundled in a single product to the final consumer. The Athens demo envisages a single mobility package that may include fare products by all TSPs. The fare products could be ticket carnets, a specific number of taxi rides, and/or unlimited bike sharing for a week. The advantage of the mobility package is that the fare products could be offered at a discounted price when purchased in the proposed bundle.

The TSPs have to register on a specific Business to Business (B2B) site and upload the fare products they are interested in the mobility package. One of the TSPs or a third party (the MaaS Operator) will then develop bilateral contracts with the other TSPs; the contracts verify the TSP’s willingness to include their fare product in the mobility package. When this procedure is terminated, the final consumer will be able to purchase the mobility package in the TC app.

The key challenge has been to bring together various organizational paradigms, existing operational systems/platforms some of which are legacy, and data models already in practice by the TSPs. In this context, the demo leader (i.e., the Centre for Research and Technology Hellas (CERTH) for the Athens demo) contributes to and coordinates the integration of individual systems into a single mobility package, in the following ways:

• Development of a mobility package. CERTH analyses the existing fare product offers and the constraints, develops when necessary new products (for example in the case of a carnet of taxi rides), and proposes product bundles, which are deployed and evaluated in the framework of “mobility packages” already explained previously.
• Journey planner. CERTH aggregates the network/service data from various TSPs’ sources, adds business logic where appropriate (for example, by introducing the service area by mode), develops a tariff calculation engine, and delivers an integrated journey planner based on the Open Trip Planner (OTP)—https://www.opentripplanner.org (accessed on 5 February 2023).
• QR code issuing. CERTH sets ups the QR code issuing server, which was absent before the pilot. The system is issuing a QR code, which is either a booking token for taxis or an e-voucher for other modes that the user may exchange for fare products in other forms (e.g., for public transport, the e-voucher may be exchanged for smart card-based tickets).
• Taxi booking. CERTH sets up a booking engine which intermediates between the TC app and the existing taxi dispatching center. By implementing this architecture, the Athens site has achieved to build on top of additional booking features without altering the existing taxi dispatching center.

3.4. Planning for Routes and Modes

The demo site is located within the Athens agglomeration and focuses on central metro stations and inter-urban rail where multiple modes are available. Although multiple transport modes operate in the area, there is limited connectivity at the level of the networks and the services to support both daily commuters and tourists. In summary, the involved PTOs and the TSPs in the MaaS Athens demonstration site are:

• OASA: is the responsible authority for planning, coordinating, and financing the public transport system in the Athens metropolitan area, covering buses, trams, trolleys and metro (3 lines);
• MIRAKLIO: is the public transport operator responsible for the buses operating within the Municipality of Iraklio, Attica;
• BRAINBOX: is a company offering bike and car-sharing services;
• TAXIWAY: is a company providing taxi services.

The main objective of this demonstration scenario is to enhance multimodality by providing integrated services, including different TSPs, through a single application that can be used by tourists and commuters. For the Athens demo, three travel cases are planned:

• Case 1: Multimodal work trip—From central Athens to any other metro station outside the central area (e.g., Keramikos station—any metro station);
• Case 2: MaaS for tourists—From Piraeus Port to any other metro station (e.g., Port–Keramikos station), for work trips and tourist arrivals;
• Case 3: Interurban/urban interfaces—From central Athens to any other metro station or site (e.g., Keramikos station—Neratziotisa station), for work and shopping/leisure trips.

A specific origin-destination trip is identified per high-level user journey to depict the methodology in this paper; the main information for each high-level user journey is provided to support MaaS planning. The presented methodology was used to identify additional origin-destination trips within the framework of IP4MaaS, however, due to space limitations, just a representative sample of these is presented. For the Athens demonstration site, the following high-level user journeys are defined in detail:

1st High-level User Journey: “Travelling to and from the northern sector of Athens for work/education (and recreation)” and refers to passengers who travel from central Athens to the Northern part of the capital (or vice versa), specifically from/to the Municipality of Iraklio to reach the place of their employment, education, and recreation. The potential origin can be the Metro Station of Keramikos, or any other metro station nearby, while, the destination is the Municipality of Iraklio. Targeted users are mainly commuters, moving around the Athens agglomeration for work, education, and/or leisure purposes. The selected user journey is:

• Origin: Keramikos station. Destination: Manpower employment organization school (OAED) at the Municipality of Iraklio.

2nd High-level User Journey: “Travelling to Keramikos district (touristic area)” refers to tourists arriving/departing to and from a central tourist district in Athens (e.g., Keramikos, Syntagma, Petralona districts). Potential transportation hubs that may be considered as origin and destinations include the Port of Piraeus, the El. Venizelos National airport, the railway station St. Larisis. Passengers are not intended to make further trips within the central district as they are considered to carry at least one piece of luggage. Targeted users are mainly passengers arriving and departing from a central district of Athens for touristic purposes. The selected user journey is:

• Origin: Keramikos metro station, egress from accommodation in the Keramikos district. Destination: El. Venizelos Airport.

3rd High-level User Journey: “Travelling to a metro station located in the peri-urban area of Attica” considered passengers traveling from central Athens to a metro station located in an interurban area, for different activities, such as work and shopping/leisure. Targeted users are mainly passengers arriving and departing from a central district of Athens for touristic purposes. The selected user journey is:

• Origin: Keramikos Metro station. Destination: “The Mall of Athens”.

Following the journey identification, all available travel solutions enabled by PTOs and TSPs involved to complete the origin/destination itinerary are considered. These solutions that have the potential to be integrated into a MaaS service are identified and presented below:

• 1st high-level user journey: A travel solution involves Taxiway, the metro service offered by OASA, and the local PT service managed by MIRAKLIO;
• 2nd high-level user journey: A travel solution involves bike/car sharing services offered by Brainbox paired with both a bus and a metro covered by OASA;
• 3rd high-level user journey: A travel solution with two different metro legs, both covered by OASA and the option of using the Brainbox car or bike-sharing service to cover the last mile.

Considering the selected MaaS travel solutions, it is essential to describe for each origin/destination trip the current pain points and areas of potential improvement. These may be related to:

• Journey planning (e.g., no integrated journey planning involving multiple TSPs, no door-to-door trip, no timetables for the planned journey, no real-time updates).
• Booking/Buying (e.g., paper-based tickets, no integrated tickets/mobility packages available, no refundability, no additional services available).
• Services offered during the travel (e.g., live navigation not available, notifications of disruption not available, no re-planning, no re-accommodation).
• Ticket validation (e.g., difficulties in finding validation machine, demagnetized ticket/card, multiple validations required, etc.).
• Ticket inspection (e.g., demagnetized card/ticket, multiple inspection mechanism, etc.).
• Other services.

Figure 3 maps the existing travel conditions for each planned origin-destination trip when planning for MaaS and outlines in detail the pain points (PP) that are considered in each step of the three trips (A to C).

4. Athens MaaS Implementation and Results

The MaaS demonstration in Athens was launched in July 2022, being the first pilot in a series across Europe, testing various forms of multimodal travel and functionalities. More specifically, the demo was launched on the 11th of July 2022, and focused on enhancing multimodality by providing journey planning and integrated ticketing through a single Travel Companion application. Over the course of two weeks, real travelers used the Travel Companion app during their journeys, and they were asked to fulfil a survey afterward, sharing their experiences. The app enabled the MaaS implementation for the selected high-level journeys and different user categories. The travel experience that is enabled in each step of the trip is presented in Figure 4.

Prior to the initiation of the actual demo phase, a wide dissemination strategy was planned and implemented. Various pieces of dissemination material were prepared including posters, leaflets, and brochures, as well as messages presented in Variable Message Signs (VMSs), onboard screens, and at metro stations. The dissemination strategy took place in the most prominent terminals in Athens (i.e., National Airport, Piraeus Port, etc.) and major public transport stations. Moreover, 500 brochures were distributed at the Greek Organization of Tourism, 500 at the City of Athens Organization, and 3500 at the Organization of Road Transport. Through this material, information was provided to potential participants regarding the demo's actual dates, registration process, guidelines for downloading, installing, and using the app, and a link to review the terms and conditions of using the app. All these, were coupled with extensive dissemination actions through social media, websites of participating organizations and companies, as well as additional digital communication channels. In order to attract as many users as possible, incentives were provided, such as free public transport tickets (i.e., 27€ cards, which is the cost of a monthly ticket for all public transport modes).

The target user groups were both local commuters and tourists visiting the city during that particular time period. The actual selection of the period that the demo took place (i.e., July) was selected by considering that Athens attracts a considerable number of tourists during summertime and the majority of locals are not yet on vacation.

Once the demo was officially launched, 140 users were registered to participate. The functionalities that were tested include the journey planner for the whole Attica Region, bike issuing, taxi booking, and Location Based Experiences (LBE). Out of the 140 users, only 12 removed their consent, while 32 of them registered as users of the BRAINBOX (bike sharing) app and 15 actually rented a bike. About 57% of testers were 25–44 years old and 43% were 45–64 years old, while 57% of all testers were female and 43% male.

By the completion of the demo, the participants received an email urging them to complete a survey that aimed to assess their satisfaction when using the TC. Through this survey, participants were asked to rate the functionalities of the app in terms of cost and time efficiency, planning process and overall satisfaction level, and the possibility of using more the PT. The email was sent several times as a reminder to participants to take the survey, resulting in 17 responses.

The number of users that participated in the demo application in Athens was as high as 140, while the number of users that completed the survey was 17. This results in a response rate of 12%. According to Smartsurvey [55], an acceptable response rate lies somewhere between 5% and 30%, leading to the conclusion that the achieved in this case response rate provides valuable feedback to base the conclusions upon.

Moreover, factors that may affect the response rate are topic salience, invite personalization, selectivity, pre-notifications, reminders, and incentives [56]. In the framework of the particular pilot application and due to GDPR issues, the whole user recruiting procedure was anonymous. This fact left no room for personal contacts to further mobilize users to take the survey and becomes a lesson learned for future similar attempts; no matter how important the protection of privacy issues is, sometimes it hinders direct feedback from users.

The feedback received, showed that the overall feeling of the demo was very positive, as users were very excited to know that attempts were being made to develop a MaaS app for Athens. Despite the deep interest of users in implementing an app for simplifying multimodal trips in the city and its surroundings, the overall assessment of the demo execution contributed to the identification of significant challenges. These challenges are thoroughly presented and discussed in the following section, leading to specific recommendations for a successful implementation of MaaS in a metropolitan area, such as the city of Athens.

5. Discussion

The planning and implementation process of the MaaS scheme in the city of Athens exposed several challenges faced during the preparation of the demonstration activity. The following subsections present the challenges, recommendations to overcome these challenges, and lessons learned from the perspective of the demo leader (i.e., the CERTH).

5.1. Implementation Challenges

Previous studies identified MaaS implementation barriers and highlighted their interrelation [27,45,46]. Hasselwander et al. [12] grouped barriers into technology, organization, and environment, with the most critical ones being data-related issues, the difficulty of transport integration and planning for different transport modes and coordinating intermodal trips, and the lack of supporting infrastructure. Lack of expertise and experience boosts existing uncertainties regarding roles and responsibilities in the MaaS ecosystem. Poor governance frameworks for MaaS were emphasized by the City of Madrid that attempt to decentralize services from the city center to efficiently promote intermodality for residents that live in peripheral areas [41]. MaaS barriers or enablers are usually related to infrastructure (E-tickets), hard institutions (E-tickets, regulated public transport fares, standardized APIs), soft institutions (open APIs, prevailing car ownership culture, trust between operators, trust between public and private sector) and capabilities (need for transport investments (public and private)) [57].

The MaaS demonstration in Athens initially revealed challenges at the technological, legal, and organizational levels, that were discussed among involved stakeholders:

• Currently, the public transport provider does not require a booking service; therefore, this functionality was not applicable for the first high-level journey.
• In the case of public transport, the TSP operates a rechargeable contactless card-based ticket that can be purchased at stations and online. Cards may be loaded at the stations, at automatic vending machines, or through the respective card mobile application (i.e., through NFC technology). There have been several discussions to integrate this service within the TC app, but it has been concluded that this is not possible due to several technical and administrative issues. An alternative solution has been devised: if the user wishes to purchase public transport tickets, they would have to use the TC app to generate a QR code voucher that may be exchanged for an ATH.ENA card at the TSP’s ticket offices. The user will then use the card for their desired trips.
• The existing public transport card (i.e., ATH.ENA card) and ticketing system cannot be directly integrated within the TC app, due to legal, contractual, and practical reasons. Each TSP has a different way to deploy issuing; nevertheless, issuing is under development for all TSPs, including taxis, public transport, and bike sharing. The bus service of MIRAKLIO is excepted since it is a free service.
• The bike-sharing TSP (i.e., Brainbox) uses a top-up e-wallet payment method, therefore it is not possible to integrate it directly within the TC app, which accepts a standard PT ticketing scheme. The user will be able to purchase a ticket/coupon for a bike, but actual booking, paying, and unlocking of the bike will be performed by using the Brainbox application. To overcome this challenge, demo partners proposed to allow the user that plans a trip with the bike sharing service to download a PDF file. This file will include a link to Brainbox’s app, as well as instructions on how to use the app and purchase a ride. The user will have to use the link to be directed to the Brainbox app and proceed with booking, unlocking, and payment. This is because of the liability of the user for damages/theft/vandalism of the bikes. The unlocking/locking functionality for the bike service is not foreseen within the TC app.
• In the case of the taxi service, issuing entails the generation of a token/QR code upon booking in the TC, which the user will present to the taxi driver to ensure that the user participated in the demo. Since payment for taxis cannot be completed through the TC at this stage, a fixed fare for taxi trips is envisaged. To achieve this, the taxi TSP divided Athens into fare zones and defined specific fixed costs by zone. In this way, the user may know for a planned journey, the cost of the ride given a specific zone of Athens.
• Lastly, a QR code-based ticketing technology requires both certain hardware and software infrastructure investments, in order to be successfully adapted and functional.

Overall, it is important to consider that users tend to prefer simple and easy tools, preferably avoiding the need for multiple downloads to use different functionalities. Language is also a barrier, and users prefer MaaS apps entirely translated in the local language.

5.2. Lessons Learned

In agreement with Sochor et al. [58], public transport is considered to be the core of the integrated MaaS scheme, therefore TSPs should collaborate closely with public transport operators and providers since TSPs’ performance within a MaaS scheme may challenge the reputation that public transport providers maintain with their customers. The following list summarizes the discussion on foreseen issues that emerged during the planning and implementation of the MaaS scheme.

• Mobility packages are composed of several attributes; raw services are packaged by the broker and offered to end users who purchase them in the form of subscription plans or pay-as-you-go [59]. In our case, to overcome technological challenges related to this issue, a support application was built for TSPs to create mobility packages. In the case of package offers, the suppliers that participate in the MaaS scheme must add at least one mobility package to the system; once this requirement is met, the package owner will select the suppliers that will participate in this offer. Once the package is configured, the owner will publish it, all involved suppliers sign it and a contract is generated and stored in the suppliers’ accounts. The following options to define the parameters of the mobility package are required: package name, TSP, transport mode, validity period, type of ticket (e.g., 1-day pass, 3-day pass, etc.), and cost. Ho et al. [60] used the number of trips for bike-sharing and UberPOOL and Guidon et al. [61] used distance for car-sharing to define trip parameters. Mobility packages for potential users should be elaborated before demo configuration by considering various business objectives and using data analysis for users’ traveling habits such as time, mode, and location. Thus, user traveling data and clustering of users to provide customized mobility packages will likely increase the success of the MaaS scheme.
• The absence of an existing digital ticket solution is a key issue for integrating various travel entitlements of the TSPs into the MaaS scheme. In fact, the migration from a smart card-based ticketing to a QR code-based system or a relevant digital solution may be costly and not feasible due to existing contractual restrictions (i.e., the existing Athena card system runs under a PPP contract). A potential solution could be to maintain the existing public transport card and integrate it with the TC app. By using this approach, digital tickets could be bought through the TC app and loaded on the ATH.ENA card through the NFC protocol.
• MaaS users in the Athens demo preferred the pay-as-you-go scheme based on the survey they took after the completion of the demo. Payment methods for MaaS services have been studied in previous studies that have shown that user preferences vary given different user characteristics. For example, users in Sydney with no car preferred to subscribe to MaaS packages, whereas infrequent car users are most likely to prefer the pay-as-you-go option [62], whereas individuals with more unimodal car behavior seem less inclined to adopt MaaS [63].
• Regarding the journey planning for bikes, information on bike availability and battery level should be provided to travelers through the MaaS app. It should also be noted that bikes were only bookable for up to one hour in advance, which is an obstacle when planning for travelers that want to book in advance.
• Users were not informed in regard to several real-time disruptions. Overall real-time disruption notifications, especially related to the public transport provider, were currently not available.
• The MaaS scheme integrated an add-on, the LBE, which aimed to improve the tourists’ experience in local points of interest and increase the uptake of the app in the long term. Users assessed it as a positive add-on, and they would like to have the option to select more virtual reality add-ons. Other studies have implemented add-ons related to parking [61] and service guarantees [64]. It should be mentioned, however, that although add-ons were found to improve the travelers’ experience, when these are not well-designed and integrated within the MaaS app, they crash, or are not accompanied by clear guidelines on how to use them, they resultin travelers’ frustration and discouragement to further use the MaaS app.
• Incentives that were provided for promoting MaaS were positively assessed by potential users and they urged their maintenance within the MaaS platform. Although such incentives are welcome at the beginning of a MaaS scheme, when the number of users increases it is probably not feasible to maintain them. A dynamic incentive program/policy is recommended in such cases, that changes according to the number of users within the system. Different incentives have been used in the literature, such as taxi discounts [60], fare discounts [17], transfer of unused credits [62], and all of them concluded that incentives attract potential travelers to use MaaS.
• Provision of real-time information was not available in this phase of the demo, which is considered a drawback in the implementation of a MaaS scheme. Provision of real-time information and reporting of incidents along a planned journey is considered an essential parameter for travelers, in order for them to control their trips, and search for alternatives. The importance of real-time data has been stressed in the literature as it has the potential to change travelers’ behavior and increase public transport ridership [65]

The literature showed that effective MaaS implementation depends upon collaboration between public and private entities [27]. The development of MaaS requires a new stakeholder ecosystem, with modified roles and increased inter-organizational collaboration. As a consequence, new inter-organizational barriers are expected to arise. Organizational barriers are those that originate from the focal firm’s organization as a whole, while intra-organizational barriers originate from sublevels of the organization, such as departments, teams, projects, or individuals. MaaS can only work if the majority of the dominant transport service providers are convinced to join. A consequence of this is that the concept of MaaS is vulnerable to the support of specific actors [66].

The current application is covering a wide range of functionalities for the end user, ranging from critical ones such as trip planning and real-time information, to “nice to have”, such as grouping of trips for example. There are also plenty of functionalities addressing the needs of the transport service providers, such as fare products’ registration to the system, development of mobility packages, etc. However, many of the functionalities require a high degree of integration effort, while others do not take into account the actual conditions for real-life integration with legacy systems. The basic development principle is: one development fits all, which is not suitable for many of the demonstrators. As a result, in many cases, the potential functionality although developed, cannot be demonstrated because this integration is too expensive or even not possible. Future consideration shall be envisaged for a more tailored integration focus for a variety of local conditions

Although the MaaS demo was implemented in urban and interurban areas of Athens, it is worth mentioning that expansion of a MaaS scheme in rural or/and sparsely built areas will likely be less cost-effective. Central Athens is characterized by densely inhabited areas, however, within the last years, peri-urban areas have been developed, however in these areas public transport coverage is still lower and insufficient. Implementation of MaaS in rural areas depends on the available mobility solutions in each area, the local incentives, and funding to support local transport. An economically viable MaaS system is supported by a large number of users, thus appropriate business models have to be adopted to fit the needs of each location.

Successful stakeholder engagement in the early stages results in a higher acceptance for MaaS. Eventually, stakeholder engagement should evolve towards more structured and permanent collaboration forms that enable strategic functions, as well as evaluation and oversight, which should lead to the achievement of desired mobility patterns and environmental objectives.

Most of the lessons learned through the IP4MaaS demo application are valid in almost all geographical contexts and therefore, the method described in this paper may be transferred to multiple practitioners as well as researchers dealing with the development of MaaS applications or even simpler mobility applications. The fact that users do nοt like to use complex systems, while they prefer to use them in their own language is global and should be taken into consideration by all interested parties. Furthermore, one of the basic prerequisites for the creation of an integrated system, irrelevant to the number of companies participating and to the geographical context in which the system will be used, is the ability for individual systems to be open and integrable. Restricted systems comprise a contradiction in the framework of the MaaS scheme development. Finally, the identification and provision of suitable incentives, based on the type of users and transport modes, is of imperative importance and comprises a transferable conclusion to all interested researchers.

6. Conclusions

The delivery of innovative services like the MaaS, requires extensions in current activity-based modeling, considering the dynamic context of modern lifestyle, social influence, ICT, responses to travel recommendation systems, attitudes, subjective considerations, and the increasing degree of uncertainty. Thus, a critical reflection on how to expand current activity-based models and their underlying theories and choice models is needed to better capture the comprehensive nature of the travel behavior and decision-making process related to MaaS [4]. The novelty and fuzzy nature of MaaS make it a challenge to ascertain MaaS, to explore its implications, and how to address them [4].

The Athens MaaS demo site used real data, real processes, and diverse transport stakeholders to provide a comprehensive proof of concept for demonstrating business processes and formulating business rules to expand collaboration between transport providers and provide directions to actors to develop customized MaaS packages. Identification of challenges at the planning and implementation level could be used to guide decision-making in other similar MaaS schemes, regarding mode selection, creation of incentives, development of mobility packages, and formulation of policies to shift travelers’ behavior towards using and benefiting from MaaS. The major challenges that were faced are related to technological and legal issues, and more specifically they relate to lack of interoperability among involved TSPs, data protection, and lack of open traffic data frameworks to ensure that dynamic public transport may be shared among involved stakeholders. To overcome these challenges, a set of supportive tools and methods were used, such as QR codes, re-direction to other apps by providing a link, and mobility package application. Although these solutions worked in the context of the demo, they also prove the need of addressing MaaS challenges for building a competing mobility service that is reliable, satisfies user needs and improves accessibility for all users.

Except for demo challenges that were mentioned in earlier sections that might be considered as MaaS implementation limitations, the present study has additional limitations. The basic ones may be attributed to the number of users who participated in the MaaS demo due to its short duration (i.e., two weeks) and the low maturity level of the application. However, following other MaaS applications that were tested within the framework of projects [46], a period of two weeks was determined to be sufficient to draw conclusions for MaaS implementation. The MaaS scheme was demonstrated in Athens, Greece, and therefore results may not be transferable to other countries with different regional characteristics. The findings regarding challenges for MaaS implementation did not differ from the literature findings, which reveals that during the first implementation phase, the main challenges are similar to literature given a different location.

This limitation may be addressed in future research related to MaaS planning and implementation. Challenges may differ for different MaaS system maturity; thus, challenges may be compared across cities that also had previous MaaS experience. For the same location, a first period of MaaS implementation should be followed by a second period of MaaS implementation and record MaaS utilization rates to study potential changes and factors that lead to different rates. As the authors of this study believe that the maturity level of the MaaS application remains a critical component towards engaging and maintaining MaaS users, future research should also focus on desired app features, by using extensive surveys, to optimize them.

The planning and provision of MaaS schemes, similarly to other innovative shared mobility services such as ridesharing [67], is a complicated task that should take into consideration the local and regional characteristics (i.e., socio-demographics, user travel habits, geography, available transport modes, economy, etc.). The development of dynamic MaaS mobility packages is directly linked to the exploration and identification of local characteristics and the development of supportive business models. To this end, future research is required for the development of a mobility platform for identifying the combination of modes, the geography in which this combination should be provided, and the business models for promoting them; thus, guiding the interested stakeholders in creating sustainable MaaS schemes in the future.