Who should control Mobility as a Service?

This story first appeared in the June issue of AutoTalk – CLICK HERE to download the magazine FREE

Mobility as a Service (MaaS) is a means of providing people with easy access to a variety of transport services, such as public transport, ride-share, and rental vehicles/devices, typically via smartphone “app” or internet website.

A pertinent question is: Who should develop and manage MaaS services?

Three approaches have appeared to date:

Private transport operators

Many transport providers develop MaaS apps for their own services; examples include Ola (rideshare) and NextBike (bike-share).This is particularly relevant for operators that provide multiple transport options they wish to vertically integrate.

For example, Uber’s acquisition of Jump bike/e-scooter shares enable it to provide a wider range of transport options through its app.

While dedicated operator apps enable easy automatic payment mechanisms to be set up, different apps are required for each operator.

A traveller also has to manually check each app to compare potential journey options.

Public government transport organisations

An alternative approach is to have centralised transport organisations develop their own MaaS systems incorporating a wide range of transport options available, eg, NZTA’s “Choice” app for Queenstown’s bus, ferry, taxi and other transport services.Choice does not handle payments directly to operators though.

This approach relies on all transport operators providing their system data via some publicly available data feed or Application Programming Interface (API).

It is difficult to obtain all relevant service data from private operators and ensure that it is up-to-date.
Even trickier is the ability for MaaS systems to handle payments across multiple providers.

While public organisations invest significant money into developing MaaS platforms, often the “official” app is considered far more clunky to use than alternative independently developed offerings.

Independent software developers

Another approach is to have third-party providers develop and maintain apps themselves.

While some independent MaaS systems are essentially just aggregators of transport service information with little ability to book/pay for services (eg, Transit app, Google Maps), some are integrating the full travel experience.

For example, with the Whim app in Helsinki, travellers can plan and pay for trips across public transport, bikeshare, taxis, and carshare.

Whim offers various pay-as-you-go and monthly subscription options and takes a small commission from trips booked with transport providers.

The success of independent app providers is again dependent on the ability to tap into available transport service data feeds and APIs.

There is strong motivation for independent developers to develop a useful MaaS offering that will be widely picked up by users and operators alike, so the apps are often high quality and updated frequently.

Comparison of approaches

Different approaches have differing advantages and disadvantages and certain trends are apparent within the three main options.

Table 1 attempts to summarise the key differences.

The biggest challenge is integrated booking and payment systems.

While many providers have seamlessly provided this within their own apps, few systems have attempted to co-ordinate real-time booking and payment of multiple providers.

Some third-party providers (like Masabi) are attempting to provide common ticketing systems, but it is slow going.

Effective use of any MaaS system requires access to good transport service data.To enable consistent availability of transport information, standardised means of presenting such data have been developed, eg, General Transit Feed Specification (GTFS).

Many private providers have developed proprietary data formats for their own apps rather than making them available to others via open APIs.

One way to encourage greater openness by transport providers is for jurisdictions to require open APIs when seeking to operate in their area (as done in Washington DC for private bike-share companies).

Conclusion

MaaS systems are still rapidly evolving, as various transport providers and service aggregators vie for market share and public agencies attempt to find their role as providers and regulators/promoters.

For this reason, no obvious best fit solution is apparent yet in the provision of MaaS, and many organisations have stepped in to fill perceived gaps.

In New Zealand, it is probably not in the sector’s best interests for government organisations to attempt their own MaaS systems.

Software development is a complex business and not one that government is placed to lead and maintain.

Rather, government agencies could help independent developers produce effective MaaS systems by:Developing or promoting common transport service open data standards like GTFS.

Insisting that open data APIs are required of any private transport operators wishing to trade in NZ.

Developing common transport booking and payment systems that can be implemented by MaaS app providers and transport operators.

Helping to fund the development or upgrading of independent MaaS app providers to achieve more integrated transport offerings.

Subsidising private transport operators that are helping to fill specific needs within the broader transport system not easily met by public agency solutions.

By focusing on these initiatives, government becomes the enabler, rather than the provider, of well-integrated MaaS services in NZ.