88 Business Model Cases: Evidence Basics

88.1 Start With the Decision

A useful demo does not prove that a service will save money. A business case starts with a baseline, cost, and test window.

88.2 Route Overview

This is part 1 of 3. Continue with Business Model Cases: Transfer and Lighting Services.

88.3 Part Objectives

• Build an IoT business case from a stated baseline and measurable change.
• Separate observed benefits from assumptions and transfer limits.

88.4 Overview

This first route treats case studies as transfer tests, separates facts from assumptions, and develops the service-value evidence behind Lighting as a Service.

This is part 1 of 2. Continue with Business Model Cases: Proposals and Economics for the second focused route.

88.5 Start With the Story

Test Who Gains, Who Pays, and What Breaks at Scale

Picture a factory choosing between buying connected lights and paying each month for light as a service. The monthly offer may lower the first cost. It also ties value to long-term operation, repair, data, and a supplier that must remain able to serve.

Start with the customer job. Name the result they will pay for, such as safe light, lower energy use, or less repair work. Separate that result from a device feature. A live chart has no value if it does not change a useful choice.

Draw the value path. Who buys, uses, installs, supports, and benefits? A building owner may pay while tenants feel the change. A service team may carry the repair cost. Keep each role visible in the case.

Then draw the money path for one unit and one year. Include hardware, install, setup, support, failed visits, replacement, service work, and end of life. Add the cost of the worst common site, not only the easy pilot.

State each public fact with its source and date. Mark estimates as estimates. A case story often reports success without showing every cost or failed site. Do not turn missing detail into proof.

Test the joined operation. Remove the outside service. Change the account owner. Replace a unit. End the contract. Ask what the customer can still do, which records they receive, and who pays to remove or keep the equipment.

Check the data promise. Name each fact collected, why it is needed, who can see it, how long it stays, and whether the customer expects that use. Selling or sharing a record is a new value path and a new risk, not free income.

Run a small scale test. Multiply support calls, failed units, travel, storage, and service load by the planned customer count. Add a bad month and a slow-paying customer. Compare cash timing with the cost of keeping the promise.

Use the same questions on each case: customer job, payer, benefit, evidence, operating work, data use, failure, exit, and scale. This makes unlike offers easier to compare without copying their surface features.

Record the transfer limit. A model that works in a dense city may fail in remote sites. A plan for owned buildings may fail with tenants. A premium product may carry support cost that a low-price unit cannot.

Keep an open-risk list with an owner and next test. A business case is a decision record, not a victory story. It should make the reason to stop as clear as the reason to invest.

Ask a support worker to price one hard case from the record. Ask a customer to explain the value in their own words. A gap between those answers is a useful warning.

Review the case after a year of real service. Compare planned and actual work, loss, exit, and customer use. Keep the miss as evidence for the next offer.

Keep the old plan beside the result.

This simple test cannot reveal private costs or guarantee future demand. Practitioner compares offers and builds the financial record. Under the Hood works through payback, contract length, pricing, and data value with explicit assumptions.

Picture comparing several IoT businesses and asking why some became durable while others stayed pilots. This chapter reads business-model case studies as patterns: who pays, who benefits, what data improves the service, and which operational costs can quietly break the model.

88.6 Learning Objectives

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

• Analyze Business Model Transformations: Explain how traditional companies transition to IoT-enabled service models
• Evaluate Financial Impact: Calculate the revenue and margin improvements from Product-as-a-Service
• Identify Success Factors: Assess the key elements that enable successful IoT business model shifts
• Apply Lessons Learned: Extract actionable insights from real-world case studies

88.7 IoT Business Case Studies

A business model is simply how a company makes money. These case studies show how real companies changed from selling physical products once (like selling a light bulb) to offering ongoing services (like charging a monthly fee to keep a building perfectly lit). Think of it as the difference between buying a DVD and subscribing to a streaming service — the streaming model builds a longer relationship and often earns more over time.

88.8 Prerequisites

This chapter assumes:

• Prior Reading: IoT Business Model Fundamentals and Pricing Strategies
• Business Concepts: Understanding of revenue, margin, CapEx vs OpEx
• Strategic Thinking: Familiarity with competitive positioning concepts

88.9 MVU: Minimum Viable Understanding

Core concept: Real-world IoT business transformations succeed by shifting from one-time product sales to recurring service revenue — the hardware becomes a platform for long-term customer relationships, not the end product.

Why it matters: Connected products change when revenue is captured, who owns operating risk, and how long the provider must keep delivering value. Public examples such as Philips/Signify’s Lighting-as-a-Service at Schiphol show the pattern; the financial models below are labeled when they are illustrative rather than reported company economics.

Key terms to know:

• Lighting-as-a-Service (LaaS): Selling illumination outcomes via subscription instead of light fixtures
• Razor-and-Blade: Subsidizing hardware to drive recurring ecosystem revenue
• Data Monetization: Converting sensor data into sellable insights with proper consent
• Customer Lifetime Value (LTV): Total revenue from a customer over their entire relationship

88.10 Asset Tracking Unit Economics

The deeper subsidised-hardware arithmetic now lives in Asset Tracking Unit Economics Contracts, covering per-device recurring margin, LTE-M connectivity cost, cloud cost, hardware subsidy payback, reporting-frequency sensitivity, churn risk, lifecycle state, and cost tags that let finance reconcile telemetry with subscription economics.

88.11 Price the Missing Repair Visit

Take an illustrative lighting service with 20 fixtures. The customer pays £6 per fixture each month, so recurring revenue is 20 × £6 = £120 per month. Assume routine running costs of £40 per month. The remaining £80 is a contribution toward hardware, installation and other costs; it is not yet profit. Over a full year with no cancellations, that contribution is £960.

Now include a repair visit costing £160, including travel and labour. One such visit consumes two months of contribution, since £160 divided by £80 per month equals 2 months. If the service model assumed that the customer would replace failed lamps, but the contract promises provider repair, the earlier economics leave out a real obligation. A dashboard cannot close that gap.

The evidence should distinguish a measured visit rate from an estimate. Suppose the pilot observes one failed fixture among 20 during a short trial. That observation establishes that replacement work occurs. It does not establish an annual failure rate for every building. Older wiring, higher mounting points and travel distance may change the cost of ownership at the next site.

Consider a customer who pays the subscription while a tenant saves the electricity. The financial benefit and the invoice now land with different people. The value proposition must explain why the payer accepts that split. Lower energy use may help the tenant, while fewer repair calls may help the owner. Counting the same avoided visit as a saving for both parties would inflate the case.

Before reading on, predict the effect of two changes. If a second £160 visit occurs during the year, the contribution falls from £960 to £640 after both visits. If the customer cancels halfway through the year, the provider cannot claim the full twelve months of recurring revenue. These checks connect the business model to service delivery: who performs the work, when cash arrives, and which risk remains after a device sale.

88.12 Continue to the Next Part

Carry this evidence into Business Model Cases: Transfer and Lighting Services, which begins with Case Studies as Transfer Tests.