Monetizing IoT: Approaches to tie it together
This article is the final in a six-part series about monetizing IoT. Find the previous article here.
In earlier articles, I evaluated the monetization framework’s three levers that impact pricing: monetization models, monetization metrics, and product structure and packaging. The series also describes the IoT solution stack, which is a pyramid that contains three levels of the solution to be monetized: the large number of the edge devices and firmware; the fewer number of gateways that connect the edge devices and aggregate their data; and the single instance of a cloud analytics and control platform to gain insights from the devices in the network, which in turn might also communicate down the stack to manage or control the operation of the edge devices. With the previous elements in mind, evaluate these sample monetization approaches:
Monetize layer-by-layer, then collectively
First, consider a solution where pricing is applied at each level of the IoT stack. For example, assume that you’re monetizing an industrial IoT solution. Smart valves are at the bottom of the stack. A gateway layer is comprised of programmable logic controllers (PLC) and software. At the top of the stack is an analytics and control cloud-based solution that gathers information about the devices and communicates with various systems in the IoT headquarters to facilitate material planning and service calls. This provides advanced analytics to the operations personnel. Layers will be monetized individually, then collectively.
IoT stack level: Edge. These are physical valves with function and value provided by a combination of hardware and embedded software. For example, a product manager might decide to monetize the edge controllers with the following monetization levers:
- Model. The model is selected to match the physical nature of the device and the associated capex purchase model. It is often perpetual, with software maintenance to provide service and updates. Selling this with a perpetual model matches the perception that the device is a key element in a mission-critical factory and can’t be allowed to stop running because of an expiration event for a time-based model.
- Metric. The volume of liquid through the controller measured in gallons per hour.
- Product structure and packaging. There are two different options: base product, which is the base value that controls flow through the valve; or dd-on product, which is an option that will automatically shut off the valve and send a message to the controller if there is a problem detected in the flow.
IoT stack level: Gateway. These are physical devices called PLCs with connectivity to both the edge devices and the cloud analytics and control layer. This is a more complex device than the edge devices because they have rich functionality that can be monetized in more creative ways. Initially, the relatively straightforward monetization model selected will be designed with the following monetization levers:
- Model. Again, this is a perpetual model and the device is monetized similar to the edge devices due to its physical nature, capex buying model and need for high availability, such as no exposure due to a subscription expiration.
- Metric. Several metrics were chosen, based upon the different products being offered at the product packaging and structure level. The metrics will be the number of attached devices per instance of a PLC, and data throughput of the PLC to the cloud analytics and control platform measured in GB per month.
- Product structure and packaging. The two following initial structures were sold: Base PLC using the attached devices metric described above; and PLC connectivity option, using the data throughput metric described above.
IoT stack level: Cloud analytics and control. This is for the cloud or SaaS platform that runs on a dedicated public cloud, such as AWS, or private cloud. This is inherently a software-based service with ongoing costs and value, so it will be sold using a recurring revenue model. Being a data aggregation, reporting and control platform with various potential integrations to different back-office systems that manage material management, there are many different offerings that can be created. For simplicity, just a few common offerings selected by the product manager will be illustrated, with the following monetization layers:
- Model. A subscription-based model with usage rights, access to updates and a base level of services enabled for one year at a time. Longer term, it will also be sold with 2- and 3-year terms.
- Metric. The metrics chosen to represent scalability as the solution grows will be the total number of maximum connected PLCs in the network that are being managed by the cloud analytics platform and the total number of systems that integrate with the cloud analytics solution.
- Product structure and packaging. The three following initial structures were selected: Base management platform; advanced reporting option; and system integration option.
Other possibilities for monetizing IoT solutions
As an alternative to monetizing the individual elements of the stack, assume that the combination of the offerings above were provided by a single provider as a total solution. If that initial deployment of the solution for the customer was to produce laundry detergent, the overall model might be to monetize by the gallons of laundry detergent per year. Of course, some analysis is required to finalize the price, but it’s a much simpler way to sell the solution.
Approaching monetization within this framework will leave you well positioned for IoT success.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.