This is the second of a short series of articles that aims to try to better define the requirements, limitations and pitfalls to try to avoid when delivering Digital Mobility Platforms (DMP’s) (previously referred to as MaaS) within a UK devolved transport environment.  As per the first article, there are examples of great practice around the world, there are even a couple of examples from the UK.  But it must be acknowledged that the current devolved and decentralised transport landscape in the UK does make the delivery of any type of integrated transport more challenging.

In this article we will cover the basic building blocks that  would generally be identified as requirements for any digital mobility platform.  However, as identified in the first article, requirements will vary depending on population densities, the physical transport network that exists, whether active, shared services should be included, whether micromobility options exist, what ticketing and payment solutions should be integrated, and of course the strategic objectives, including the platform’s longer-term financial security. 

Before embarking and describing the proposed cornerstones, or building blocks, of MaaS, it should be understood that DMP’s can only be as good as the underlying transport options that support the community, however much the DMP provides the best possible information. 

It’s generally a fair indication that if ridership is decreasing the public transport solution isn’t accommodating the needs of the travellers.  This could be because of service availability, service frequency, overcrowding, cleanliness, cost, or any additional limitations.  But in the event of a sustained reduction in ridership, it is a suggestion that the entire transport service be assessed to identify what short to long-term changes can be made to better meet rider demands.

The Critical Building Blocks for Integrated Mobility Solutions

The following diagram identifies the critical building blocks of almost any integrated mobility platforms ranging from first-mile – last-mile solutions, journey planning solutions, customer information systems through to full Integrated Mobility platforms. 

MaaS requires the fundamental building blocks in the following graphic, which will be discussed in detail in future articles, providing a more detail in turn. The graphic is designed to convey data exchange and integration points between the various system components.  It does not indicate configuration layers, which are equally important, but these will be discussed as we start to drill down into user requirements, look and feel etc.

No two systems can or should be expected to be the same.  Shared services may differ from one implementation to another, one platform might include taxi’s, another might include car sharing.  If a solution were to be implemented in the Middle East, these may include autonomous mobility, or even autonomous taxis.  Some locations might have implemented self-contained mobility hubs where all transport modes coexist as an intermodal transport hub.  Some may have introduced EV-charging points, that co-exist with Park and Ride locations or even Bike and Ride locations.  One authority may have a business case to include shared personal car services, another may not.  But the expectation is that depending on your business case and specification you would include the elements that you need and ignore the rest. 

The following graphic identifies seven core blocks that are required for an integrated mobility platform.  To be truly successful this should be an area that is analysed, reviewed, in line with customer expectations, and a strategy developed for service improvement prior to the delivery of a MaaS specification.  Changes could include adding more shared or micro mobility services for first-mile – last-mile, plugging anomalies in the schedule, providing additional integrated night services during the weekends, or guaranteed connections at mobility hubs – but whatever the changes, this is an essential starting point on your road to delivering a truly integrated mobility solution.

Flexibility and funding

The graphic also shows that whatever flavour of Integrated mobility or your digital mobility platform you deliver, it must also be delivered around a programme of continuous improvement.  Irrespective of the level of detail you incorporate into your specification, transport requirements evolve quickly, new transport modes may be introduced, ticketing solutions will change, user requirements may develop, legislation may be amended.  Whatever the motivation, your program will evolve, and there must be the funding, and commitment to deliver improvements in line with a changing business, user or the legislative or regulatory landscape.

Likewise, there must be a long-term funding plan.  Many may disagree with this, and suggest that this is a service and as such should be funded from a public or private pot.  The problem with that is that all too often those pots run dry pretty quickly, and therefore to ensure a ‘bright future for your baby’, it will require that you also identify alternative and sustainable forms of funding that you can control, that can be initiated in the event that your primary source of funding is no longer available. This is essentially programme management 101 – always have a backup plan. Funding options will be discussed in much more detail in a future paper.

In my view the heart of a digital mobility platform is the Journey Planner.  However, it must be acknowledged that Journey Planning is likely to only to be used for new journeys, where a user requires information about a new route or service.  For normal commuting type journeys, a user will generally just look at real-time notifications, arrival data, actual physical locations of the vehicle or service, or just to top-up or purchase new tickets.  Nevertheless, the journey planner should be considered the absolute foundation stone of your DMP, particularly when public transport is coupled with micro mobility, intermodal, shared and even active services and offerings, which is where a DMP comes into its own.

Journey planning and integrating services

Everyone has heard about multimodal journey planning, which is generally a reference to multiple public transport modes being seamlessly integrated to provide the best possible itinerary, including walking routes to and from stops and at interchange points.  But unless we are addressing modal shift, are we doing anything more than arguing about the dinner bill on the Titanic? 

The term intermodal, introduces the opportunity to bring into journey planning; private, shared and other active modes, such as taxis, bike and scooter sharing, as well as private car and bike options that can provide private journeys to interchange points where there are good ongoing public or shared services that can be used to continue or complete your journey.  This would be, for example, to a mobility hub where EV charging locations are available to park and ride or even bike and ride locations. 

However, this is significantly more complex than it sounds – the DMP must not only identify the outbound journey, but must also identify the best options for the return journey, must take account of the opening and closing times of the facility, the costs associated with parking and whether services are available when the driver wants to go home.  All of this must be factored in at time of planning to ensure that a driver doesn’t get left stranded and is unable to get home.

Coming next

The next article will concentrate on the heart of your digital mobility platform in much more detail, showing the elements that can, should or could be implemented depending on your business case and user requirements.  It will address personalisation requirements, mobility requirements for a range of users, feedback mechanisms, and even touch or alternative data collection opportunities.