91 Business Model Cases: Proposals and Economics

91.1 Start With the Story

A facilities team understands why lighting could become a service, but it still has to approve a contract. The proposal must show cash flows, risks, payback timing, and what changes if equipment life, energy prices, or service promises differ from the sales case.

91.2 Overview

This route turns the service idea into a proposal, compares lifetime economics, and tests razor-and-blade and data-revenue models before selecting a fit.

This is part 2 of 2. Review Business Model Cases: Evidence and Service Value when you need the first route.

91.3 Learning Objectives

By the end of this chapter, you will be able to:

• build an evidence-bound Lighting-as-a-Service proposal
• compare lifetime cost, payback timing, and discount-rate effects
• evaluate razor-and-blade and governed data-revenue models

91.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

91.5 Lighting-as-a-Service Proposal

This proposal comparison is an illustrative campus-scale model. It uses round numbers to teach TCO and NPV reasoning; it is not reported Schiphol contract pricing.

Scenario: A university campus facilities manager receives two proposals for replacing 50,000 aging fluorescent fixtures across 15 buildings.

Proposal A (Traditional): Purchase 50,000 LED fixtures outright at $200 each = $10M upfront. Estimated 15-year maintenance cost: $3.75M ($250K/year). Annual energy cost: $1.2M (calculated at $0.12/kWh, 200W average per fixture, 12 hours/day).

Proposal B (LaaS): Zero upfront cost. Monthly service fee: $45K/month ($540K/year) for 15 years = $8.1M total. Philips guarantees 99.5% uptime, handles all maintenance, replaces fixtures after 7 years, and commits to 50% energy reduction vs. current fluorescent system.

Question: Which proposal delivers better Total Cost of Ownership over 15 years?

Step 1 - Calculate Proposal A Total Cost:

• Initial hardware: $10M
• Maintenance (15 years): $3.75M
• Energy: $1.2M/year x 15 = $18M
• Total: $31.75M

Step 2 - Calculate Proposal B Total Cost:

• Service fees: $540K/year x 15 = $8.1M
• Energy (50% reduction): $0.6M/year x 15 = $9M
• Total: $17.1M

Step 3 - Compare Outcomes:

• Savings with LaaS: $31.75M - $17.1M = $14.65M (46% TCO reduction)
• Cash flow advantage: No $10M upfront CapEx improves balance sheet ratios
• Risk transfer: Philips bears technology obsolescence risk (new LED tech in years 8-15 automatically deployed)

Key Insight: The LaaS model’s value comes primarily from energy savings ($9M vs $18M) enabled by newer, more efficient LED technology and continuous optimization—not just from avoiding maintenance costs. The upfront CapEx elimination is a secondary benefit that improves financial metrics but doesn’t drive the economic case.

91.6 Deep dive: LaaS vs Traditional TCO

Use this calculator to compare Total Cost of Ownership between traditional hardware purchase and Lighting-as-a-Service models.

// Visualization: Cost Breakdown Comparison
{
const width = 640;
const height = 400;
const margin = {top: 40, right: 120, bottom: 60, left: 80};

const data = [
{model: "Traditional", category: "Hardware", value: traditional_hardware, color: "#2C3E50"},
{model: "Traditional", category: "Maintenance", value: traditional_maintenance_total, color: "#7F8C8D"},
{model: "Traditional", category: "Energy", value: traditional_energy_total, color: "#E67E22"},
{model: "LaaS", category: "Service Fees", value: laas_total, color: "#16A085"},
{model: "LaaS", category: "Energy", value: laas_energy_total, color: "#E67E22"}
];

const svg = d3.create("svg")
.attr("width", width)
.attr("height", height)
.attr("viewBox", [0, 0, width, height])
.attr("style", "max-width: 100%; height: auto;");

const models = ["Traditional", "LaaS"];
const x0 = d3.scaleBand()
.domain(models)
.range([margin.left, width - margin.right])
.padding(0.2);

const categories = ["Hardware", "Maintenance", "Energy", "Service Fees"];

const y = d3.scaleLinear()
.domain([0, d3.max(data.map(d => d.model === "Traditional" ? traditional_total : laas_with_energy))])
.nice()
.range([height - margin.bottom, margin.top]);

// Group data by model and stack
const stacked = d3.stack()
.keys(categories)
.value((d, key) => {
const item = data.find(i => i.model === d.model && i.category === key);
return item ? item.value : 0;
})
(models.map(model => ({model})));

const colorMap = {
"Hardware": "#2C3E50",
"Maintenance": "#7F8C8D",
"Energy": "#E67E22",
"Service Fees": "#16A085"
};

// Draw stacked bars
svg.append("g")
.selectAll("g")
.data(stacked)
.join("g")
.attr("fill", d => colorMap[d.key])
.selectAll("rect")
.data(d => d)
.join("rect")
.attr("x", d => x0(d.data.model))
.attr("y", d => y(d[1]))
.attr("height", d => y(d[0]) - y(d[1]))
.attr("width", x0.bandwidth());

// X axis
svg.append("g")
.attr("transform", `translate(0,${height - margin.bottom})`)
.call(d3.axisBottom(x0))
.selectAll("text")
.style("font-size", "14px")
.style("font-weight", "bold");

// Y axis
svg.append("g")
.attr("transform", `translate(${margin.left},0)`)
.call(d3.axisLeft(y).tickFormat(d => `${"$"}${d3.format(".2s")(d)}`))
.selectAll("text")
.style("font-size", "12px");

// Y axis label
svg.append("text")
.attr("transform", "rotate(-90)")
.attr("y", margin.left - 60)
.attr("x", -(height / 2))
.attr("text-anchor", "middle")
.style("font-size", "14px")
.text(`Total Cost (${contract_years} years)`);

// Title
svg.append("text")
.attr("x", width / 2)
.attr("y", 20)
.attr("text-anchor", "middle")
.style("font-size", "16px")
.style("font-weight", "bold")
.text(`${contract_years}-Year TCO Comparison: Traditional vs LaaS`);

// Legend
const legend = svg.append("g")
.attr("transform", `translate(${width - margin.right + 10}, ${margin.top})`);

categories.forEach((cat, i) => {
legend.append("rect")
.attr("x", 0)
.attr("y", i * 25)
.attr("width", 15)
.attr("height", 15)
.attr("fill", colorMap[cat]);

legend.append("text")
.attr("x", 20)
.attr("y", i * 25 + 12)
.style("font-size", "12px")
.text(cat);
});

return svg.node();
}

Try adjusting: Increase energy rates or operating hours to see how energy savings drive LaaS value proposition. Notice how the NPV savings are higher than nominal savings due to deferred LaaS payments.

91.7 Deep dive: Discount Rates in Long Contracts

The Mistake: Comparing 15-year contract costs without applying time-value-of-money discounting. $540K paid in Year 15 is worth far less than $540K paid in Year 1.

Why It Matters: At a 5% discount rate, the $8.1M nominal LaaS payment stream is worth only $6.2M in present value terms. The traditional purchase’s $10M upfront payment stays at $10M PV because it’s paid immediately.

Correct Approach: Always calculate Net Present Value (NPV) for multi-year IoT contracts:

• NPV = Σ (Payment_year / (1 + discount_rate)^year)
• Use your organization’s Weighted Average Cost of Capital (WACC) as the discount rate
• Factor in tax implications: CapEx may be depreciable, OpEx is immediately deductible

Real Impact: In the university example above, proper NPV analysis would show LaaS savings of $18M (not $14.65M) because the deferred payments have lower present value than the upfront hardware purchase.

Decision Framework for Product-as-a-Service Evaluation:

91.8 Philips Business Model Journey

After the financial model, step back from the spreadsheet and look at the operating journey. The timeline matters because service revenue only becomes durable when financing, maintenance, customer trust, and circular asset handling mature together.

The following diagram illustrates the key stages of Philips’ transformation from traditional hardware sales to Lighting-as-a-Service, showing how each phase built upon the previous one.

91.9 IoT Business Model Comparison Framework

This diagram compares the four major IoT business model archetypes covered in these case studies, showing how each generates revenue differently.

IoT business model archetypes

Product-as-a-Service

Example: Philips LaaS

Revenue: Outcome-based subscription

Signal: Provider retains asset and service responsibility

Subscription / Razor-and-Blade

Example: Smart speaker ecosystem model

Revenue: Hardware subsidy plus recurring services

Signal: Subsidy only works when attach-rate revenue repays it

Pay-per-Use

Example: Rolls-Royce Power-by-the-Hour

Revenue: Metered usage tied to customer activity

Signal: Price follows actual consumption, not ownership

Data Monetization

Example: Agricultural telemetry insights

Revenue: Aggregated analytics sold to third parties

Signal: Governance and consent matter as much as the data itself

Comparison of the four major IoT business model archetypes and the revenue logic behind each one.

91.10 Knowledge Check: Case Study Analysis

91.11 Razor-Blade Economics

Lighting-as-a-Service keeps the provider close to the asset. The next pattern does the opposite at first: it lowers the entry-device price and bets that recurring ecosystem value will repay the subsidy before churn catches up.

91.12 Razor-and-Blade Check

Scenario: A smart-speaker provider sells a hub below cost to grow its installed base. The ecosystem model below is illustrative: it assumes revenue from music subscriptions, smart-home purchases, and shopping margin. The point is to test whether the recurring attach-rate revenue repays the hardware subsidy.

Think about:

1. If the provider loses $75 per device but earns $594 over 3 years under these assumptions, what’s the net profit per customer?
2. Would this strategy work if ecosystem LTV was only $150 instead of $594?

Key Insight: A razor-and-blade strategy sells or subsidizes the entry device to drive recurring services. Low-cost hardware reduces adoption barriers, but the model fails if attach rates, retention, or service margin do not repay the subsidy.

Revenue Breakdown (3-Year LTV):

Business Model Comparison:

Financial Calculation:

• Hardware loss: -$75 (average subsidy per device)
• 3-year ecosystem LTV: +$594
• Net profit per customer: $519
• Breakeven timeline: 4.5 months ($75 / $16.50 monthly)
• Illustrative customer ROI: 692% over 3 years

Why This Works in the Model:

1. Low adoption barrier: $59 price point vs $200+ competitors
2. Ecosystem lock-in: Voice shopping, music, smart home create switching costs
3. High-margin services: 70-80% gross margin on digital services vs 20-30% on hardware
4. Platform network effects: More devices leads to more developers leads to better ecosystem leads to more devices

Calculation note: The $594 LTV is a scenario assumption, not a reported company metric. In a real model, product teams should validate attach rate, retention, margin, and attribution before subsidizing hardware.

Similar Razor-and-Blade Models:

• HP Instant Ink pattern: Printers and ink subscriptions show how recurring consumables can subsidize competitive hardware pricing
• Peloton: Bikes with monthly class subscriptions ($1,495 bike, $528/year subscription)
• Kindle: Devices subsidized, e-book revenue ($120 device, $15/book x 20 modules/year = $300)

Verify Your Understanding:

• If a smart-speaker device costs $110 to manufacture and sells for $59 (a $51 subsidy), but the ecosystem generates $594 over 3 years, would the strategy still work if only 50% of customers actively used ecosystem services (reducing LTV to $297)? What would happen to the ROI ($297 - $51 = $246 vs $519)?

91.13 Razor-and-Blade Check

Use this razor-and-blade check section as a guided decision record, not as a list to memorise. First identify the stated input, assumption, or scenario; then compare each option on the same units and time boundary. Next check which value changes the outcome and which evidence would reveal an invalid assumption. For razor-and-blade check, the useful result is the reasoning chain: observed condition, governing constraint, calculation or classification, and operational consequence. Record that chain before choosing an answer or carrying a value into the next section. Where the panel supplies several choices, reject each distractor against the chapter’s named mechanism instead of relying on wording cues. Where it supplies a table or timeline, compare rows at like-for-like scale and preserve the difference between an early indication, an actionable threshold, and a final outcome. This turns razor-and-blade check into evidence that can be reviewed, recalculated, and connected to the running design narrative.

Checkpoint: Subsidy Payback

• You now know that a smart-speaker-style subsidy must be recovered by attach-rate revenue, retention, and margin.
• You can recompute the chapter’s baseline: $594 over 36 months minus a $75 hardware loss leaves $519 net profit per customer.
• You can explain why the same model becomes fragile if ecosystem LTV drops to $150 or if active usage cuts the revenue base.

91.14 Deep dive: Razor-and-Blade ROI

Calculate the return on investment for hardware subsidy strategies such as a smart-speaker ecosystem model.

// Visualization: Cumulative Profit Over Time
{
const width = 640;
const height = 300;
const margin = {top: 40, right: 40, bottom: 50, left: 70};

const months = Array.from({length: 37}, (_, i) => i);
const cumulative = months.map(m => (total_monthly * m) - subsidy);

const data = months.map((m, i) => ({month: m, profit: cumulative[i]}));

const svg = d3.create("svg")
.attr("width", width)
.attr("height", height)
.attr("viewBox", [0, 0, width, height])
.attr("style", "max-width: 100%; height: auto;");

const x = d3.scaleLinear()
.domain([0, 36])
.range([margin.left, width - margin.right]);

const y = d3.scaleLinear()
.domain([d3.min(cumulative), d3.max(cumulative)])
.nice()
.range([height - margin.bottom, margin.top]);

// Zero line
svg.append("line")
.attr("x1", margin.left)
.attr("x2", width - margin.right)
.attr("y1", y(0))
.attr("y2", y(0))
.attr("stroke", "#7F8C8D")
.attr("stroke-width", 1)
.attr("stroke-dasharray", "4,4");

// Area under curve
const area = d3.area()
.x(d => x(d.month))
.y0(y(0))
.y1(d => y(d.profit))
.curve(d3.curveMonotoneX);

svg.append("path")
.datum(data)
.attr("fill", net_profit_36 > 0 ? "#16A085" : "#E74C3C")
.attr("fill-opacity", 0.3)
.attr("d", area);

// Line
const line = d3.line()
.x(d => x(d.month))
.y(d => y(d.profit))
.curve(d3.curveMonotoneX);

svg.append("path")
.datum(data)
.attr("fill", "none")
.attr("stroke", net_profit_36 > 0 ? "#16A085" : "#E74C3C")
.attr("stroke-width", 2.5)
.attr("d", line);

// X axis
svg.append("g")
.attr("transform", `translate(0,${height - margin.bottom})`)
.call(d3.axisBottom(x).ticks(12))
.selectAll("text")
.style("font-size", "11px");

svg.append("text")
.attr("x", width / 2)
.attr("y", height - 10)
.attr("text-anchor", "middle")
.style("font-size", "12px")
.text("Months");

// Y axis
svg.append("g")
.attr("transform", `translate(${margin.left},0)`)
.call(d3.axisLeft(y).tickFormat(d => `${"$"}${d3.format(",.0f")(d)}`))
.selectAll("text")
.style("font-size", "11px");

svg.append("text")
.attr("transform", "rotate(-90)")
.attr("y", 15)
.attr("x", -(height / 2))
.attr("text-anchor", "middle")
.style("font-size", "12px")
.text("Cumulative Profit");

// Title
svg.append("text")
.attr("x", width / 2)
.attr("y", 20)
.attr("text-anchor", "middle")
.style("font-size", "14px")
.style("font-weight", "bold")
.text(`Razor-and-Blade ROI: Breakeven at Month ${breakeven_months !== "N/A" ? Math.ceil(parseFloat(breakeven_months)) : "N/A"}`);

// Breakeven marker
if (breakeven_months !== "N/A" && parseFloat(breakeven_months) <= 36) {
const be_month = parseFloat(breakeven_months);
svg.append("circle")
.attr("cx", x(be_month))
.attr("cy", y(0))
.attr("r", 5)
.attr("fill", "#E67E22");

svg.append("text")
.attr("x", x(be_month))
.attr("y", y(0) - 10)
.attr("text-anchor", "middle")
.style("font-size", "11px")
.style("fill", "#E67E22")
.style("font-weight", "bold")
.text(`Breakeven: ${breakeven_months}mo`);
}

return svg.node();
}

Try adjusting: Lower the retail price to increase subsidy, then watch how attach rates impact breakeven time. Notice how small attach rate improvements dramatically change ROI.

91.15 Common Misconception: Data Monetization

Once recurring value is clear, data can look like the obvious next revenue stream. This section slows that instinct down: telemetry becomes revenue only when a buyer, consent model, and insight product already exist.

91.16 More Data Is Not More Revenue

The Misconception:

Many IoT companies assume that collecting massive amounts of sensor data automatically creates monetization opportunities. The belief is: “We’ll gather all the data we can, then figure out how to monetize it later.”

Why This Is Wrong:

1. Storage Costs Exceed Revenue: Storing 1 TB of IoT time-series data costs $23-50/month (AWS S3/Timestream). A smart building with 500 sensors generating 1 MB/day each creates 15 TB/month = $345-750/month storage cost. Without a clear buyer for this data, it’s pure expense.

2. Data Without Insights Has No Value: Raw sensor readings (temperature: 22.3C, humidity: 45%) are worthless. Buyers pay for actionable insights such as which schedule change lowers HVAC energy use. The transformation from data to insight requires analytics infrastructure (additional cost).

3. Privacy Regulations Block Monetization: GDPR, CCPA, and sector-specific regulations (HIPAA healthcare, FERPA education) severely restrict what data can be sold and how it must be anonymized. Compliance costs ($50K-500K for data governance systems) often exceed potential revenue.

4. Anonymization Reduces Value: To legally sell data, companies must anonymize it (remove PII). But anonymization eliminates 60-80% of commercial value—advertisers pay 10x more for identified user data ($50/user/year) vs anonymized cohorts ($5/user/year).

Real-World Failures:

The Correct Approach:

Data Monetization Success Formula:

1. Start with Customer Problem: What decision does the buyer need to make? (Energy procurement, maintenance scheduling, inventory optimization)
2. Work Backward to Required Data: Collect only sensors/metrics needed for that decision
3. Build Analytics First: Develop insight generation before scaling data collection
4. Establish Consent Framework: Explicit user opt-in with transparent value exchange
5. Calculate Unit Economics: Ensure (insight revenue per user) > (collection cost + storage cost + compliance cost)

Illustrative Example: Agricultural Telemetry Insights

• Problem Identified: Farmers need yield optimization recommendations
• Data Collected: Soil moisture, yield maps, weather (not GPS tracking, not personal data)
• Insight Generated: “Plant corn variety X in northeast field for 12% yield increase”
• Revenue Model: Sell aggregated, consented insight products to seed companies, insurers, or research partners while giving operational analytics back to participating farmers
• Consent Model: Farmers explicitly opt-in, retain data ownership, can revoke access
• Result: Data revenue is tied to trust, transparency, and a clear value exchange rather than raw data extraction

Key Insight: Data monetization requires a clear buyer, defensible value proposition, and robust consent framework before collecting a single byte. “Big data” without “big insights” is just expensive storage.

Checkpoint: Governed Data Revenue

• You now know why data monetization starts with the buyer’s decision instead of a broad collection plan.
• You can name the cost and trust gates: storage, analytics, compliance, explicit opt-in, aggregation, anonymization, and revocation.
• You can use the agricultural telemetry example to test whether insight revenue and farmer value exchange are both defensible.

91.17 Deep dive: Data Unit Economics

Calculate whether your IoT data monetization strategy is financially viable after accounting for collection, storage, and compliance costs.

// Visualization: Cost vs Revenue Breakdown
{
const width = 640;
const height = 350;
const margin = {top: 40, right: 40, bottom: 100, left: 80};

const categories = [
{label: "Revenue", value: total_revenue_monthly, color: "#16A085", type: "revenue"},
{label: "Storage", value: -storage_cost_monthly, color: "#2C3E50", type: "cost"},
{label: "Analytics", value: -(analytics_cost_per_user * num_sensors), color: "#3498DB", type: "cost"},
{label: "Compliance", value: -compliance_fixed_monthly, color: "#7F8C8D", type: "cost"},
{label: "Net Profit", value: net_profit_monthly, color: net_profit_monthly >= 0 ? "#16A085" : "#E74C3C", type: "net"}
];

const svg = d3.create("svg")
.attr("width", width)
.attr("height", height)
.attr("viewBox", [0, 0, width, height])
.attr("style", "max-width: 100%; height: auto;");

const x = d3.scaleBand()
.domain(categories.map(d => d.label))
.range([margin.left, width - margin.right])
.padding(0.2);

const y = d3.scaleLinear()
.domain([d3.min(categories, d => d.value) * 1.1, d3.max(categories, d => d.value) * 1.1])
.nice()
.range([height - margin.bottom, margin.top]);

// Zero line
svg.append("line")
.attr("x1", margin.left)
.attr("x2", width - margin.right)
.attr("y1", y(0))
.attr("y2", y(0))
.attr("stroke", "#000")
.attr("stroke-width", 2);

// Bars
svg.selectAll("rect")
.data(categories)
.join("rect")
.attr("x", d => x(d.label))
.attr("y", d => d.value >= 0 ? y(d.value) : y(0))
.attr("height", d => Math.abs(y(d.value) - y(0)))
.attr("width", x.bandwidth())
.attr("fill", d => d.color);

// Value labels on bars
svg.selectAll("text.value")
.data(categories)
.join("text")
.attr("class", "value")
.attr("x", d => x(d.label) + x.bandwidth() / 2)
.attr("y", d => d.value >= 0 ? y(d.value) - 5 : y(0) + 15)
.attr("text-anchor", "middle")
.style("font-size", "11px")
.style("font-weight", "bold")
.text(d => `${"$"}${d3.format(",")(Math.abs(Math.round(d.value)))}`);

// X axis
svg.append("g")
.attr("transform", `translate(0,${height - margin.bottom})`)
.call(d3.axisBottom(x))
.selectAll("text")
.style("font-size", "12px")
.attr("transform", "rotate(-45)")
.attr("text-anchor", "end");

// Y axis
svg.append("g")
.attr("transform", `translate(${margin.left},0)`)
.call(d3.axisLeft(y).tickFormat(d => `${"$"}${d3.format(".2s")(d)}`))
.selectAll("text")
.style("font-size", "11px");

svg.append("text")
.attr("transform", "rotate(-90)")
.attr("y", 15)
.attr("x", -(height / 2))
.attr("text-anchor", "middle")
.style("font-size", "12px")
.text("Monthly Amount ($)");

// Title
svg.append("text")
.attr("x", width / 2)
.attr("y", 20)
.attr("text-anchor", "middle")
.style("font-size", "14px")
.style("font-weight", "bold")
.text(`Data Monetization Unit Economics (${num_sensors} sensors)`);

return svg.node();
}

Try adjusting: Increase sensor count or insight revenue to reach profitability. Notice how fixed compliance costs create a minimum viable scale threshold. At small scale, compliance is prohibitive.

91.18 Data Monetization Decision Framework

This flowchart illustrates the correct decision process for IoT data monetization, contrasting the common “collect everything” mistake with a consent-led approach that starts from a buyer problem.

91.19 Data Monetization Knowledge Check

91.20 Business Model Quiz

The final activities ask you to classify the models without flattening them into “recurring revenue.” Use the proof metric from each checkpoint: service margin, subsidy payback, governed insight value, network effects, or metered usage.

91.21 Quiz: Business Model Identification

91.22 Business Case Links

Use this business case links section as a guided decision record, not as a list to memorise. First identify the stated input, assumption, or scenario; then compare each option on the same units and time boundary. Next check which value changes the outcome and which evidence would reveal an invalid assumption. For business case links, the useful result is the reasoning chain: observed condition, governing constraint, calculation or classification, and operational consequence. Record that chain before choosing an answer or carrying a value into the next section. Where the panel supplies several choices, reject each distractor against the chapter’s named mechanism instead of relying on wording cues. Where it supplies a table or timeline, compare rows at like-for-like scale and preserve the difference between an early indication, an actionable threshold, and a final outcome. This turns business case links into evidence that can be reviewed, recalculated, and connected to the running design narrative.

Cross-module connection: Pricing Strategies explains how to calculate optimal subscription prices using customer willingness-to-pay, competitive benchmarks, and value-based pricing for Product-as-a-Service models like Philips LaaS.

91.23 Quiz: Business Model Cases

91.24 Quiz: Business Model Shift

91.25 Illustrative Math Is Not Proof

Scenario models are useful for learning, but they are not public company financials unless the source actually reports them. Keep assumptions visible: hardware subsidy, monthly margin, attach rate, churn, contract length, discount rate, and support cost. If those assumptions change, the business-model conclusion may flip.

91.26 2. Ignoring Payback Timing

A model can show attractive lifetime value and still fail in cash terms. Subsidized hardware, installation labor, onboarding, and service operations are paid early, while recurring revenue arrives slowly. Always pair LTV:CAC with payback period and churn risk before scaling.

91.27 Consent Before Monetizing

Data monetization fails when the provider collects broadly and searches for a buyer later. Start with the decision the buyer needs, collect only the required data, give the data producer a clear benefit, and preserve opt-in, revocation, aggregation, and anonymization boundaries.

91.28 Label the Diagram

91.29 Code Challenge

91.30 Summary

This chapter examined one verified IoT business model transformation and several illustrative financial models that show how connected-product revenue patterns work.

91.31 See Also

• IoT Business Model Fundamentals — Foundation concepts: CapEx vs OpEx, recurring revenue, customer lifetime value (LTV)
• Pricing Strategies — How to calculate subscription prices, freemium tiers, and outcome-based pricing models
• Go-to-Market Strategy — B2B launch strategies, sales cycles, and pilot-to-scale frameworks for IoT products
• Financial Metrics and Analysis — Master LTV, CAC, churn rate, payback period calculations for SaaS and IoT business models

91.32 In 60 Seconds

This chapter covers business model case studies, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

91.33 What’s Next