For Transit, Owning the MaaS Customer Will Hinge on Owning the Back End

Following a pandemic-driven lull, interest in pursuing mobility as a service (MaaS) among transit agencies is taking off, and for good reason. The case for providing users access to a vivid spectrum of transportation options in a single app is compelling on grounds that range from cost and convenience to urban livability and environmental sustainability. But how do we get there?

There’s a Wild West aspect to the MaaS marketplace, with scads of startups around the globe offering so many solutions — often emphasizing the front-end user-facing app — as they chase what looks to be a massive business opportunity.

That’s a good thing. Competition will hone these apps and improve usability along the way, and if they’re not compelling enough to sway the masses from always thinking “car,” MaaS will spin its wheels. But the success of MaaS in the long run — that is, a MaaS that works for riders while remaining a viable business for transit agencies and commercial transportation providers working with them — will depend not only on front-end, but also (and, I would argue, predominantly) on back-end processing that truly fulfills MaaS vision while enabling business models that work. It’s the back end, too, that will play the defining role in the most pressing MaaS-related question facing transit agencies embarking on MaaS programs: Who will own the customer?

Choosing the right path

While transit agencies from Augsburg to Denver and beyond are already working with ridesharing companies (and, in Augsburg’s case, bikeshares and other transportation providers) transit agencies don’t want to get “Expediaed” by Uber, Lyft, or anyone else. By that, I mean ceding the customer-facing front-end apps to software companies, search engines, or transportation providers who roll beyond the backbone of traditional public transit. Transit agencies own the physical assets at the heart of what should be the future urban-suburban transportation paradigm. It is in every sizable municipality’s best interest to preference these modes over single-vehicle-dominant auto travel. I believe they should own the customer as well.

Fortunately, transit agencies’ control of the core modes of bus and rail put them in a strong position to lead the MaaS transition and provide equitable service while improving their fare box recovery ratios. They can do so by embracing agile yet robust back-end platforms indispensable to the future of MaaS even as they promote attractive front-end systems.

What must such a back-end system be able to do? For one, provide the mix-and-match specificity to let users choose trips based on price, on speed and convenience, or even such factors as minimizing carbon footprint. Accomplishing that involves a full-scope sales and distribution system with advanced product configuration to integrate all mobility services by all providers in a product catalogue, break them down by service type, established the cost of each distinct service (including dynamic pricing for peak/off-peak services), and create a potpourri of possible journeys by any provider. When the customer decides on a route, the system must determine on-time status; provision based on physical stations and stopping points, mode type, and fares/fees by participating provider; and display them to the user.

Rather than today’s token-and-ticket approach, the focus of MaaS is on subscription accounts (though MaaS must handle both). When the customer embarks on a trip, the back-end system must not only manage the customer’s account, but also handle revenue allocation, billing, invoicing, and settlement for the various transportation providers involved in the trip — whatever combination of trains, buses, rideshares (and, at some point, autonomous vehicles), taxis, scooters, or whatever other combination may be.

Add to those basics the need for back-end MaaS platforms to securely update customer profiles with trip-related data (a basis for targeted promotions and cross-selling, among many other uses) and, via route-information and disruption-management systems, to keep the customer apprised of timing as well as alternative modes, rebooking options, and account-credit options. The solutions enabling all this must adhere to relevant local, state, and federal rules and regulations (and, in Europe GDPR requirements).

Looking Forward

I’m not alone in the belief that such sophisticated, high-volume back-end systems should be the domains of established players with experience ranging from industrial-strength transaction processing to retail systems. I have my own biases as far as who that player should be. But these companies must be established enough to convince transit agencies they’re not going anywhere.

They also must be big enough to lead open-standards efforts and press them through a still-chaotic MaaS-provider landscape. They must be seasoned enough to deal with the enormous number of complex real-time transactions involved in the scheduling and service delivery, account management, and payment processing and allocation that will underlie a successful MaaS business. And their core solutions must be able to handle sophisticated revenue management and apportionment among MaaS’s many players in an automated and seamless fashion — capabilities that will prove indispensable to any MaaS operator’s ultimate financial success.

I’m also not alone in the belief that MaaS programs constitute far more than peripheral business considerations for transit agencies. Success or failure in establishing MaaS as the first-choice medium for moving about will profoundly influence the livability and sustainability of our cities and will be decisive in shaping the long-term prospects of transit agencies themselves.