89 Business Model Cases: Transfer and Lighting Services
89.1 Start With the Decision
A famous case study can fail when its pricing, network, or customer duty changes. A transfer test separates facts from assumptions before the pattern is reused.
89.2 Route Overview
This is part 2 of 3. Review Business Model Cases: Evidence Basics for the preceding evidence.
89.3 Learning Objectives
- Separate case-study facts, assumptions, decisions, and outcomes.
- Test Peloton, Ring, and lighting-service patterns in a new context.
89.4 Chapter Roadmap
- Case Studies as Transfer Tests
- Facts, Assumptions, Decisions
- Case Study as Data Contract
- Checkpoint: Transfer Evidence
- Read an IoT Case Study
- Incremental Examples
- Peloton, Ring, and Data Pricing
- Concept Check: Revenue Shift
- Concept Check: Case Study Risk
- Try It Yourself
- See Also
- For Kids: Meet the Sensor Squad!
- Lighting-as-a-Service Shift
89.5 Case Studies as Transfer Tests
An IoT business-model case study is useful only when it helps you decide what can transfer to a different product, customer segment, or operating environment. The common weak reading is “Company X used connected devices and created recurring revenue, so we should copy that model.” The stronger reading separates the business mechanism from the headline. Philips/Signify’s managed lighting example is not just a story about efficient LEDs; it is a transfer test for contracts where the provider can measure the outcome, finance the asset, maintain the installed base, and price the service below the customer’s alternative cost. Rolls-Royce’s Power-by-the-Hour pattern is not just “charge by usage”; it works because engine hours are measurable, maintenance risk is central to customer value, and the provider has operational capability that the customer is willing to outsource.
Use a three-question transfer filter. First, what changed in the offer: ownership, risk, payment timing, data rights, or decision support? Second, what connected capability made that change credible: metering, remote diagnostics, firmware updates, identity, billing, or analytics? Third, what evidence would break the model in your context: churn, support cost, financing cost, regulatory limits, poor telemetry quality, or weak customer willingness to pay? A case study becomes actionable when the answer includes both the attractive model and the failure condition.
Before transferring a public success story into a new product decision, inspect Figure to separate the attractive business pattern from the evidence that makes it work. The visual turns the section’s three questions into a review record rather than a reason to copy a headline.
| Case-study question | Evidence to extract | Transfer test |
|---|---|---|
| What value is now recurring? | Subscription fee, usage fee, outcome payment, attach-rate revenue, or governed insight product | Can the customer keep seeing value after the device is installed? |
| What does connectivity prove? | Uptime, consumption, maintenance state, entitlement, environmental condition, or user behavior | Is the signal auditable enough for billing or renewal decisions? |
| Who owns operating risk? | Provider, customer, channel partner, insurer, cloud operator, or data producer | Does the party paid for the service also control the largest cost driver? |
| What can invalidate the economics? | Churn, subsidy payback, cloud cost, field service labor, privacy constraints, or sales cycle length | Which assumption would make the public case fail in this deployment? |
Read Figure from left to right. Begin with the case-study question, identify the operating or commercial evidence that can answer it, and then apply the transfer test in the final column. A recurring-value claim needs continued customer value; connectivity evidence must be auditable enough for the decision it supports; risk ownership must match control of the cost driver; and fragile assumptions must be named. That sequence carries the case study into the chapter’s running data-and-economics contract instead of treating precedent as proof.
89.6 Facts, Assumptions, Decisions
When you use public IoT case studies in a product review, keep a visible boundary between verified facts, illustrative economics, and your team’s decision assumptions. Verified facts are things the public source actually supports: a named customer, a business-model pattern, a published launch, a service scope, a pricing mechanism, or a stated operational outcome. Illustrative economics are teaching models such as a 36-month LTV, a hardware subsidy payback, or a 15-year NPV comparison. They can be valuable, but they should stay labeled because they are not the company’s reported financials unless the source says so. Decision assumptions are the numbers your team must own: attachment rate, device bill of materials, Stripe Billing or Chargebee subscription cost, LTE-M or NB-IoT connectivity cost, cloud ingestion on AWS IoT Core or Azure IoT Hub, warehouse and transformation cost in BigQuery, Snowflake, or dbt, support burden, warranty exposure, churn, and sales cycle.
The practical workflow is to build one case-study brief per model pattern. Start with a one-sentence old model and new model. Add the connected capability that changes the money flow. Then map the evidence chain from device telemetry to commercial decision. For a lighting service, that chain may run from occupancy and energy data to uptime evidence, maintenance scheduling, service invoices, and renewal proof. For an agricultural data product, it may run from machine telemetry and field context to aggregation, anonymization, consent records, analytics outputs, and buyer value. For a subsidized consumer device, it may run from identity, entitlement, subscription status, engagement, and payment retention to LTV:CAC.
The review should end with an explicit decision. “Copy Philips” is not a decision. “Pilot outcome-based lighting in three buildings only if metered uptime, maintenance cost, and financing terms keep gross margin above target after six months” is a decision. It names the model, the operating evidence, the financial guardrail, and the moment when the team should stop, revise, or scale.
89.7 Case Study as Data Contract
Under the hood, an IoT business-model case study is a chain of contracts across devices, data, money, and obligations. The device contract defines what telemetry is captured, how trustworthy it is, and which events can be used for operational or billing claims. A usage-priced compressor, lighting system, or engine-service model needs readings that are timestamped, attributable to the correct asset, resilient to outage, and reconciled when a gateway reconnects. The data contract defines identity, consent, retention, aggregation, and lineage. This is where a data-monetization case can fail: the buyer may want benchmarks, but the platform still needs a lawful and trusted path from raw farm, building, home, or fleet telemetry to an aggregated product that cannot expose an individual customer.
The commercial contract translates those signals into money. Subscription models need entitlement state, plan changes, failed-payment handling, taxation, and revenue recognition. Usage models need metering windows, dispute handling, minimum fees, overage logic, and audit trails. Outcome models need a defensible counterfactual or a narrower proxy, such as measured hours of operation instead of “failures prevented.” The operating contract then determines who pays when the model works in the spreadsheet but not in the field: device returns, truck rolls, firmware defects, cloud outages, cybersecurity incidents, consent withdrawal, and customer-success labor.
This is why case studies should be read with architecture diagrams and unit economics beside them. AWS IoT Core, Azure IoT Hub, MQTT brokers, device identity services, billing platforms, data warehouses, and CRM systems are not background plumbing; they define what the business can prove. If the architecture cannot connect telemetry to entitlement, service cost, customer account, and consent status, the model’s revenue line is fragile. A mature case-study review therefore produces two artifacts: a narrative model record that executives can understand and a data-contract checklist that engineers, finance, legal, and customer-success teams can test before launch.
Checkpoint: Transfer Evidence
- You now know how to separate a public case into verified facts, illustrative economics, and team-owned decision assumptions.
- You can trace the contract chain from telemetry to billing, consent, service cost, and renewal proof.
- You can reject a weak case-study copy when the provider cannot measure the outcome or control the largest operating risk.
89.8 Read an IoT Case Study
Use each case study as a business-model evidence record, not only as a success story.
- Name the old model. Identify what the organization sold or operated before connectivity changed the offer.
- Name the connected capability. Find the sensor, platform, data, or service loop that made the new model possible.
- Trace the money flow. Separate one-time hardware revenue, recurring service revenue, operational savings, and data-driven value.
- Check the risk boundary. Record what could break the model: financing, churn, maintenance cost, consent, security, or adoption.
Canvas practice: Before comparing the cases, sketch one model record with five fields: customer problem, connected capability, revenue mechanism, cost driver, and renewal evidence. Use the Business Model Fundamentals canvas if you need the full nine-block view.
89.9 Incremental Examples
Beginner Example: A lighting supplier moves from selling fixtures to charging for maintained illumination. The key shift is from product margin to recurring service value.
Intermediate Example: A device maker discounts hardware to grow an ecosystem. The review must compare lost device margin with recurring subscriptions, consumables, or platform revenue.
Advanced Example: A fleet platform sells aggregated operational insights. The review must test whether consent, data quality, customer segmentation, and support costs make the data product defensible.
89.10 Peloton, Ring, and Data Pricing
Use these case patterns when comparing consumer IoT models:
- Peloton: premium hardware creates the installed base, but the recurring class subscription carries the long-term margin. The risk is unit economics: high customer acquisition cost and inventory exposure can pull the LTV:CAC ratio below a healthy target.
- Ring: affordable hardware acts as a wedge into the home. Recurring value comes from optional video storage, multi-device attach, neighborhood/network effects, and ecosystem integration; privacy governance is part of the business model, not an afterthought.
- Smart data pricing: connectivity can be charged by usage, time, location, priority, transaction, or third-party sponsorship. In cellular IoT, pooled or sponsored connectivity can be more valuable than charging every user directly because it removes adoption friction and enables service revenue.
Review move: compare the first sale, the recurring revenue mechanism, the customer trust boundary, and the metric that proves the model is sustainable.
89.11 Concept Check: Revenue Shift
What question distinguishes a product sale from a service model?
Answer: ask when value is captured. A product sale captures most value at purchase; a service model captures value repeatedly as the provider maintains outcomes or insights.
89.12 Concept Check: Case Study Risk
Why can a financially attractive IoT service still fail?
Answer: the model may depend on adoption, uptime, financing, data rights, maintenance cost, or security controls that the spreadsheet does not prove.
89.13 Try It Yourself
Pick one case study in this chapter and write a four-line model record: old model, connected capability, recurring value mechanism, and strongest risk assumption.
89.14 See Also
- IoT Business Model Fundamentals - defines the model patterns used in the cases.
- Pricing Strategies - turns the case logic into pricing and margin decisions.
- IoT Use Case Case Studies - compares business logic with operational deployment evidence.
89.15 For Kids: Meet the Sensor Squad!
IoT Business Models are like choosing how to run the coolest clubhouse in town!
Imagine the Sensor Squad has built an amazing treehouse with smart lights, a weather station, and a snack machine. Now they need to decide how to let their friends use it!
89.15.1 Three Treehouse Sharing Models
Temperature Terry had an idea first: “Let’s sell the treehouse for $100! We build it, they buy it, done!”
But the LED disagreed: “What if we DON’T sell it? Instead, we charge $2 per week to use it, AND we keep the lights working perfectly. That way, after one year they’ve paid us $104 — more than selling it once — and they never have to fix anything!”
the microcontroller had a THIRD idea: “What if we give the treehouse away for FREE, but charge for the amazing snack machine and weather reports? Kids will love the free treehouse so much, they’ll happily pay $1/week for snacks and cool weather facts!”
the battery did the math:
| Sammy’s Plan | Lila’s Plan | Max’s Plan |
|---|---|---|
| Sell for $100 once | $2/week = $104/year | Free treehouse + $1/week snacks = $52/year |
| We’re done after sale | We fix everything forever | We need amazing snacks! |
| Friend owns it | We still own it | Friend gets it free |
| One friend = $100 | One friend = $104+ | Ten friends = $520! |
“Max’s plan works best when LOTS of kids join!” cheered Bella. “The more kids use the treehouse, the more snacks we sell!”
The Sensor Squad learned that in business, sometimes a company earns steadier long-term revenue by renting, servicing, or bundling a connected product instead of treating the device sale as the whole business.
89.15.2 Key Words for Kids
| Word | What It Means |
|---|---|
| Subscription | Paying a little bit regularly, like a magazine delivery |
| Razor-and-Blade | Give away the handle cheaply, make money on the blades! |
| Service | Doing something helpful for someone regularly |
| Lifetime Value | All the money one customer pays you over many years |
89.16 Lighting-as-a-Service Shift
The treehouse example shows the intuition; now the chapter turns to the first enterprise case. Keep the same question in mind: what changes when the provider sells an operating result instead of only shipping a connected asset?
Company Background:
Philips Lighting (now Signify) moved part of its commercial lighting business from one-time fixture sales toward managed service contracts. The strategic problem was familiar for IoT: LED fixtures last longer and become easier to compare, so the provider needs a way to earn from performance, maintenance, upgrades, and energy outcomes rather than only the initial hardware sale.
The Business Model Shift:
In 2015, Schiphol Group, Cofely, and Royal Philips announced a Lighting-as-a-Service arrangement for Schiphol airport terminal buildings. The public case states that Schiphol pays for the light it uses while Philips remains owner of the fixtures and installation, with the service partners responsible for performance, durability, and end-of-life reuse or recycling.
Revenue Model Transformation:
| Metric | Traditional Fixture Purchase | Lighting-as-a-Service | Change |
|---|---|---|---|
| Revenue Type | One-time hardware sale plus maintenance projects | Recurring service payment for light used | From CapEx purchase to OpEx service |
| Customer Payment | Large upfront fixture purchase | Lower upfront payment; recurring service fee | Adoption friction moves from capital budget to operating budget |
| Asset Ownership | Customer owns luminaires and replacement risk | Provider retains ownership of lighting assets | Provider has incentive to design durable, repairable equipment |
| Maintenance | Customer or facilities contractor manages failures | Service provider manages performance and durability | Operational burden shifts away from the customer |
| Circularity | End-of-life handling is a customer problem | Provider plans reuse/recycling at end of life | Product design and service economics become linked |
| Energy Savings | Customer captures savings after purchase | Contract can align service fee with efficient illumination | Efficiency becomes part of the value proposition |
Verified Schiphol Case Facts (2015)
- Schiphol pays for the light it uses rather than buying the luminaires outright.
- Philips retains ownership of the fixtures and installation.
- Philips and Cofely are responsible for performance, durability, and end-of-life reuse or recycling.
- Public case material reports substantially lower energy consumption compared with conventional lighting.
Illustrative Financial Model: Schiphol-Style Lighting Service
The following numbers are a teaching model for a large facility. They are not reported Schiphol contract pricing.
Traditional Purchase Model (illustrative):
- 10,000 LED fixtures at $150 each = $1.5M upfront
- Annual maintenance: $75K/year x 15 years = $1.125M
- Energy cost: $500K/year x 15 years = $7.5M
- Total 15-Year Cost: $10.125M
- Customer owns aging equipment after 15 years
Lighting-as-a-Service Model (illustrative):
- Zero upfront hardware cost
- Monthly service fee: $18K/month x 180 months = $3.24M
- Energy savings assumption: 50% reduction ($250K/year saved)
- Provider guarantees performance and handles maintenance
- Customer 15-Year Cost: $3.24M service - $3.75M savings = -$510K (net savings)
- Customer pays for service outcomes instead of owning obsolete hardware
Provider Revenue Calculation (illustrative):
- Service revenue: $3.24M over 15 years
- Hardware cost: $1.5M (initial) + $300K (replacements) = $1.8M
- Maintenance cost: $900K over 15 years (in-house)
- Gross profit: $3.24M - $2.7M = $540K (16.7% margin on revenue, paid over time)
- Additional value: Retained customer relationship enables future upsell (smart building integration, data analytics)
89.17 Continue to the Next Part
Carry this evidence into Business Model Cases: Unit Economics, which begins with Deep dive: Putting Numbers to It.