How OEMs Can Leverage Subscription Business Model

The subscription business model outperforms the non-subscription business as we observe the shift from ownership towards usership. The success of services like Netflix for movies, Spotify for music, Microsoft Game Pass for video games quickly spreads outside from the entertainment industry. For industries based on the services, not on physical products, the shift from one-time or reoccurring payment to subscription-based service is easier.  

Not-so-warm welcome for subscription model in automotive 

It’s harder to justify monthly payments for the service if it enables the device or feature already present in the product you have already paid for. The huge backlash in media happened in a reaction to BMW’s announcement in 2020 that the company has been considering selling heated seats as a subscription-based feature. 

Most of the criticism was associated with the fact that the overall price of the car was the same, and obviously, it was already equipped with the electric pad in the seat, while there was no additional software for handling the feature – it was just enabling and disabling the button. Some of the journalists even called that “simple-feature-as-a-service.” That resulted in nightmarish marketing for the idea and postponed the implementation of similar models by other OEMs,  encouraging them to rethink the risk of making similar announcements. 

Subscription business models become new normal 

But in the last few years, a lot has changed. People get used to the subscription payment model appreciating its benefits. Also, more and more features in the car are based on the software, so it’s just easier to justify additional payment over the initial vehicle purchase. The overall reception of the idea shifted from mostly negative to neutral or positive. 

At this point, customers understand that sometimes building-in hardware that is not activated can be cheaper than making hundreds of configuration versions. Also, the vehicle manufacturers start to learn how to better advertise the benefits of the subscription business model and how to better pick the features that fit this kind of model. It also enabled certain flexibility if this is a corporate vehicle, with basic default configuration, and the driver would like to add Apple CarPlay or enable additional convenience features, like opening the car with the smartphone. 

How OEMs can successfully implement a subscription model 

 For OEMs planning to start with this business model, the moment for building a platform supporting subscription-based services is now. Not just the payment system, because the subscription business model is based on the idea that the feature can be enabled and disabled on the fly, basically making Connected Car a key requirement, while OTA makes it much more robust long-term. 

It all starts with requirements. Let’s try first to distinguish typical types of feature purchase for a vehicle: 

• Standard equipment (automatically activated in production phase) 
• Runtime – associated with the driver or limited-time licenses 
• Lifetime – associated with the vehicle, does not expire 
  • Purchased on an initial configuration in a dealership 
  • Purchased aftersales (either in dealership or online)
• Subscription – associated with driver or vehicle, can expire
  • Automatic re-subscription (e.g., no end time) 
  • Manual re-subscription (e.g., end time after X months) 

 The other key aspect is offering differentiation between countries, regions, and continents. The same feature may be available as a subscription in the EU while only available as a one-time purchase in the USA. 

To make the offer complete, the manufacturer may allow buying a custom offer specific to geographical location – for example, the additional package offered when the driver enters Nürburgring – 24 hours of additional racing time-tracking features. 

Building a system for the new model 

Our system has to handle all those use cases. To accomplish that, we need to build a solution in which the scheduler (sometimes called cron, from the name of Linux job scheduler) is the core component. It is responsible for triggering notifications or events at specific periods – for example, resubscription notification monthly, to trigger the payment, or license cancellation event after a configured period.

The scheduler itself is just a single, small part of the system. The other important piece is the database for storing the subscription status and the API backend for retrieving and updating the values. Consistency is crucial, as the feature getting disabled by mistake leads to a bad user experience. 

The system has to be connected to the vehicle. In most cases, this is done asynchronously through queues like Kafka or RabbitMQ. This gives better stability and reliability than direct connections.  

Lastly, we need to ensure that the feature is actually enabled or disabled in the vehicle. This means the vehicle has to receive the correct, unique license for that feature when it’s enabled, and revoke it when it is disabled (alternatively, the license can be automatically pushed every, for example, 30 days, with expiration time set to 33-35 days, to prevent feature loss when connectivity or payment problems occur. 

To avoid building an additional retry mechanism into the licensing system itself, it’s better to update the feature state using Digital Twin. In this case, the digital representation of the vehicle is updated with the new license, and it is then responsible to synchronize itself with the vehicle when the internet connection to the car is available. This makes the system conformant to the single-responsibility principle, so the license system does not have to know or understand the vehicle connectivity.  

That’s the basic architecture of our system for handling licenses and subscriptions of digital services. Obviously, that’s just the beginning. For OEMs, where the scale of digital business grows exponentially, the next important topic would be the reliability of the system. For that, scaling to meet the demand is important, as well as caching the current state of licenses to avoid complex queries. 

Apart from that, this is enough to start with the feature activation and deactivation and handling subscriptions. Of course, it must be connected to mobile apps and online stores for purchases and to payment systems, but those are already used by most enterprises.  

Is this really the future? It seems like we can’t avoid it anymore, especially with shared mobility growth, the ability to unlock temporarily additional features is tempting. Imagine grabbing a Ferrari for a weekend to take it to the track, enabling an additional 50HP and an advanced AI for measuring your times and proposing a better moment to break before the turn and accelerate afterward. And paying for only 2 days. This may make all the difference in convincing customers to the new subscription business models.