Categories
moveID Ecosystem

The Mobility Service Commerce Process

Imagine a world where mobility services—those lifelines of urban existence—are organized in a decentral way such that for instance a mobility service like “Airbnb for parking and charging” electric vehicles becomes possible. Such services can thrive within a decentralized ecosystem, orchestrated by cutting-edge technologies. Welcome to the realm of the GAIA-X project moveID.

After giving an introduction to its decenral mobility service ecosystem, this article lays out a blueprint commerce process that customers go through when consuming a mobility service that is organized in a decentral way. The post shows the most important roles and information systems required to realize such a process and lays the groundwork for a decentral mobility service ecosystem.

Introduction to a decentral mobility service ecosystem

At its core, moveID stands for “Mobility Identity.” The vision of moveID is to reshape how mobility services are offered, can be discovered, transacted, and consumed — with the help of technologies that help in decenralization:

  1. Self-Sovereign Identity (SSI): Imagine a digital passport—one that you control, not some bureaucratic entity. That’s SSI. In the moveID universe, the digital identity of vehicles, drivers, and fleet owners helps to organize access to mobility services in a frictionless and seamless way with Verifiable Credentials. And that all happens while you decide who sees these credentials, when, and why. Whether you’re a commuter, a scooter rider, or a cargo shipper, your SSI opens doors to mobility services without compromising privacy.
  2. Distributed Ledger Technology (DLT): Think of DLT as a decentralized, tamper-proof record of transactions. In the moveID ecosystem, DLT powers seamless payments, transparent routes, and trust among participants. No intermediaries and no hidden fees.

See these article for a deeper introduction into moveID’s target vision and technical component landscape.

Commerce process for mobility service ecosystems

The following swimlane diagram depicts moveID’s take on a rather general blueprint version of a commerce process for mobility services in a decentralized ecosystem. An example for a mobility service of moveID’s commerce process could be parking or charging for an electric vehicle.

Mobility Service Commerce Process by the GAIA-X 4 moveID project
Mobility Service Commerce Process (CLICK to download and view a high resolution PDF – with example instantiations of roles and descriptions in addition)

To explain the swimline, the horizontal axis shows the successive process steps, which are mainly inspired by customer journey for mobility services. The vertical axis organizes all the economic components (i.e., roles such as service provider) and technical components that are needed to conduct the process steps. In combination, the process steps and the roles and technical components (or “systems”) form the field of action in the centre of the swimlane. The boxes in the centre of the swimlane represent the actions to be performed by a role within a process step and the arrows are meant to read as information flows that trigger another action.

This process is divided into seven consecutive phases, namely the Onboarding, Discovery of Service, Booking, Access Control, Consumption, Payment, and Settlement phases. The corresponding roles to conduct these phases are the Service User, Mobility Service Provider, Registry/Catalogue for Mobility Services, Mobility Infrastructure Provider, Payment provider, Transaction layer provider and the Identity Provider. Example instantiations are given when clicking on the swimline to retrieve a high-resolution and extended version of the commerce process.

The process begins with the user familiarizing themselves with GAIA-X and especially moveID and downloading an app to connect to the decentral mobility service world and to onboard themselves with a digital identity. Users can then search for and compare the various mobility service offerings by consulting the service catalog. Users can book a specific service, and the Mobility Infrastructure Provider reserves the corresponding period of service usage for the user.

A Verifiable Credential for accessing the physical part of a mobility service (such as a parking lot or a charging station) is issued to the user. The user can then drive to the location where the service is located and use the service for the duration of the booked period by presenting the Verifiable Credential for getting access. After verifying the Verifiable Credential, the user is granted access to the service, which in turn enables the user to consume the service. Finally, the payment process is started, and a receipt is generated.

Conclusions

  1. Getting abstraction right to distill the essence
    The process required considerable abstraction. Abstraction is a challenging task, to choose details to omit. But we think our efforts have been successful. Considering actions and information flows in the process, they can potentially trigger various further actions in the subsequent process phase and often multiple paths through the process phases could be designed. Nevertheless, by abstracting complex details and making choices to the information flows, we have distilled the essence of the process into a manageable service blueprint that deliberately covers only one page and only one information flow variant.
  2. Identifying key process steps and roles
    Via our analysis we gained valuable insights into the critical process steps. We identified the essential economic roles (e.g., service providers) and the technical information systems (e.g., digital identity providers and transaction systems) required for the process.
  3. Essential components for the setup of a mobility service ecosystem
    Our swimlane highlights what fundamental building blocks are needed to establish a decentral mobility service ecosystem. In another deliverable, we will use these building blocks as core parts for designing the incentive system to participate in the ecosystem. Other projects and endeavours, possibly also from “Future Mobility” project familiy, may use this blueprint to shortcut their own efforts. And they may use differing instantiations of the abstract roles while our full-PDF swimlane version already shows some possibilities for the moveID realm. For operations, some specific ones have to be selected.
  4. Informing external stakeholders
    This work is not just for moveID’s benefit, it rather also targets external stakeholders needed to spin up the envisioned mobility service ecosystem in a decentral way. By focusing on the big picture in our process blueprint, we enable smoother collaboration and shared understanding with external stakeholders.

Note that this article was written together with Vincent Geilenberg and colleagues from the Zeppelin University and in part with the help of generative AI.

2 replies on “The Mobility Service Commerce Process”

Hi! I’d like to see cross reference of this work. DePIN doesn’t have (or need) Gartner. But would like to explore independent evaluation on tech parameters for scale for this project. My objective is to have cross reference from published papers or published quantified results/benefits with open points or future growth areas. In sum, what’s the assessment and maturity level of these project(s)? I find it extremely difficult to explain or even start this conversation in my current consulting company with traditional decision makers.

Hello Surabhi. Agree with your point. The idea was to have a simple approach to understand the technology first. For a deeper dive with reference points and proof points please reach out for the same.

Leave a Reply

Your email address will not be published. Required fields are marked *