Business models

This working group is dedicated to editing the business model section of the certification mark and as of June 16th on draft 0.1 reads as:

NB: The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” are used as described in RFC 2119.

 

Introduction

IoT devices require an ongoing service in order to work.  The ongoing delivery of that service – which may include connectivity, updates etc. – will cost money. So the vendor needs to have a business plan/model which covers the cost of that service, otherwise they will be forced to terminate it eventually. Models include:

  • Pure Product: Pay for the hardware, get the service for free for a limited time
  • Pure Service: Pay as you use, no up-front. May be lock-in.
  • Hybrid.

 

The way the customer “pays” might be:

  • With cash
  • With data
  • Profit-sharing, e.g. classic as-a-Service model: “I replace your lightbulbs with LED, and we share the savings”. Or e.g. solar rent-a-roof. Turning capex into opex. Outsourcing responsibility. Making intervention financeable.

The above within some “bundling” arrangement which makes the connection between the cost and the benefits less direct, e.g. where the IoT proposition is part of some broader proposition that the user is paying for (e.g. user receives a connected thermostat for “free” as part of their energy tariff)

 

A vendor MUST:

 

Provide transparency setting-out the agreement with the customer, specifically:

  • The goods and/or services that the user will receive
  • How the user will pay for these services (e.g. cash or data?)
  • What other use is being made of user’s data (e.g. a “multi-sided” business model such as reselling aggregated data, using it to target advertising to the user etc.).
    • If other parties are involved, the same obligations MUST be passed-on, and this agreement applies in turn to whoever it is passed on to.
  • Whether there are other obligations on the user, e.g. if they’re buying car insurance via a monitoring device, they might have an obligation to provide valid data.
  • The duration of these terms (e.g. for how many years is device support guaranteed?)
  • If vendor wants to change the above, vendor MUST first ask permission from the user (not just notify, or silently change terms).
  • The above MUST all be explained in simple language.

 

If data are part of the agreement then clarity MUST be provided regarding:

  • Retrievability of user data  (e.g. that user can remove right for vendor to use data”)
  • Traceability of user data (e.g. if user wants to audit where their data has gone)

 

Interesting facts/thoughts

  • In a particular region of Italy, Valle d’Aosta, if you want state funding you have to provide a “certified business model”, certified by e.g. a bank or a holding company or an accountant
  • Although data cannot be “owned”, databases and the data in them canbe owned, as property.
  • IoT’s ongoing service requirement is analogous to the ongoing availability of consumables (e.g. ink, filament for 3D printing etc.), and of repair.
  • EU law now defines a minimum guarantee period of 2 years for products sold to consumers. But what about the services associated with IoT products? And what about B2B sales?
  • Given that IoT is an early market, there’s a lot of uncertainty about the value to the end user, therefore pricing and business models are very likely to change, causing ripples through the supply chain. This makes all relationships more like partners than vendor – there will be ongoing rebalancing of value and cost to keep value and cost roughly in balance and this will require flexible, close relationships, not arms-length.
  • Renault Zoe car “owners” discovered that for the first year they weren’t actually allowed to sell the car, because they didn’t technically own it.

Discussion moderated on June 16th @ ZSL London Zoo by Pilgrim Beart