This is the second installment in a series of three on how to evolve your Internet of Things solution for Product as a Service and subscription business models.
In my previous post, I highlighted the key components of a PaaS-enabled IoT solution: the connected product (connected device or other service endpoint), an entitlement management system that orchestrates the product usage eligibility or level of service, a CRM, and a monetization engine, which fulfills charging and billing functions. Let’s take a closer look at these components.
Device usage data collection
The manufacturer of a smart, connected product has already incorporated data collection into the product itself. Collected data has many purposes: it allows for remote monitoring and diagnostics, it feeds back into R&D for product improvements, and it is also used as part of the preventive maintenance process.
However, with the onset of the PaaS business model, additional data must be collected from the device – data that describes the usage of the product for the charging purposes. It can be anything from the distance of the journey, number of printouts, counted hours of engine thrust, to the number of analyzed samples or MRI jobs performed. In many cases these data points will be used as input to the monetization engine which will apply price points to be used in the final settlement.
When designing the smart, connected product for the PaaS model, the following aspects of data collection must be considered:
- What are the key data points on which the pay-per-use pricing will be based? Depending on the nature of the product and the industry it may be a single qualifier (number of MRI scan jobs) or multiple points (distance driven and number of days). Ideally the product should collect multiple usage related data points to allow for building competitive pricing models depending on changing market conditions, customer demographics or competition.
- Collecting auxiliary or complimentary usage related data points – these will play a key role in monetizing any additional services. For instance, the hospital pays the device manufacturer for each MRI scan performed; an example of an add-on service is the consultancy of the scan result with the external specialist using the device’s built-in desktop sharing capability. Such add-on service must generate a specific event on the device (or in the cloud) which will be associated with the asset and then priced accordingly.
The IoT connectivity is able to address the concerns mentioned above. An IoT agent (software running on the device responsible for exchanging the data with the IoT platform) shall be modified to read the usage data from the device and then transmit it back to the IoT platform where the usage aggregation is going to happen.
Secondly, it is recommended to design the device in such a way that it provides constant feedback to the end user. Ideally the PaaS-enabled IoT solution will signal the local user with the current state of usage related counters. This will serve the following purposes:
- Allow the user to understand how much of daily, weekly, monthly, etc. “quota” has been consumed;
- Avoid bill shock by over using the device;
- Avoid the situation when the service is cut off (end of entitlement) without previous clear warnings.
Currently available techniques (alarms, events, real time data monitoring) can enhance the user experience; for example keep the user informed if abnormally high usage is detected. For example, the number of MRI scan jobs are above running average or industry standard, etc.
Lastly, the IoT solution by design requires the products to be connected to the network and transmit to and from the IoT platform. However, the design should incorporate mechanisms to cater to the situations when connectivity is down due to infrastructure issues or due to policies (i.e. hospital allowing the device to be connected to the network only outside of business hours). The device must be equipped with a queuing mechanism to continue collecting the usage statistics despite the interruptions in connectivity.
The entitlement management system controls which product’s features a given user is eligible to use over a unit of time. Depending on industry, product type, criticality of the product function, the entitlement management can be realized on various levels of technical sophistication.
On one side of the spectrum it may be implemented via a straight forward on and off flag directly in the IoT platform. The account manager can set this flag on a device (or set of devices) once negotiation with the lessee has been completed. The IoT platform will propagate the flag down to the IoT agent and the device itself. As a result, the device will enable or disable its features available to the end user.
More advanced implementation will involve a more dedicated entitlement management or license management system which, most likely will integrate with a CRM, and will control when and for which devices the features shall be enabled or disabled. The complex hierarchy of features and sub-features can be modelled with such an approach but the end result will be the same – the device will automatically receive information from the IoT platform when the license is active, when the license has expired and potentially when it has been renewed.
When implementing the entitlement management, the following aspects must be considered:
- How critical is the product function? If the license expires does it make sense to cut off the service, or limit product function, or shutdown the device automatically? In many cases this will not be a viable approach if the result would be endangerment of life, health or property.
- What technical measures shall be implemented to warn the end user or lessee about potential entitlement approaching its end? End user can receive the warning distributed by the IoT Platform while the lessee will most likely be notified by the CRM system.
The monetization engine will play key role in a PaaS-enabled IoT deployment – this will be the system responsible for generating finance documents – invoices for product users and settlements with 3rd party providers (application, service or content).
Selection of the appropriate monetization engine (or rating and billing package) will play a key role in the way that the PaaS offerings are going to be priced and marketed.
It is important to keep the cost of the charging system in line with expected ROI per connected device and, on the other hand, it should offer a flexible pricing structure to model future offerings without major redesign of the solution.
The rating and billing market is a very crowded space. There are very large players, who for decades have been entrenched in telecom or cable industries with legacy packages primarily targeted to Communication Service Providers. On the other side there is a large amount of medium and small players providing packages geared towards specific industries. One thing all these vendors have in common is the desire to put their foot in the IoT and M2M space.
In my next post I will focus on the monetization engine and the essential qualities it must possess in order to support PaaS-enabled IoT deployment. Stay tuned for more!