A logistics company equips its vehicle fleet with GPS and temperature sensors. The pilot wraps up in three months: sensors perform well, data flows to the central system, the operations manager delivers a polished presentation. Then what happens? The project gets frozen. The reason isn’t budget — it’s the absence of a clear answer to one question: what does this system cost the business annually, and what measurable return does it produce? When that question goes unanswered, the IoT project dies at the pilot stage.
The Internet of Things concept is straightforward in principle: attach sensors and connectivity to physical assets and turn them into data-generating nodes. Factory machines, warehouse shelves, vehicles, containers — all become sources of operational data. The technical infrastructure to make this happen is increasingly available: GSM networks, RFID readers, embedded sensors, and central data collection platforms can now be made to work together. In Turkey, mobile penetration is high, 3G coverage is broad, and the enterprise software ecosystem has matured. The technical barrier has come down. But the core problem was never technical.
The real obstacle is the absence of a revenue or savings mechanism designed to cover connectivity costs. Every sensor carries a monthly data transmission cost. Every device requires maintenance, firmware updates, and eventual replacement. Central software comes with licensing or hosting fees. Together, these form the total cost of ownership — and for a small pilot, that number looks manageable. But when you scale from 50 vehicles to 500, or from 10 machines to 200, costs grow linearly. If the savings or revenue model doesn’t scale in parallel, the system can’t grow. A system that can’t grow loses its investment rationale entirely.
Successful IoT deployments share a common structure: the savings or revenue logic is built into the system architecture from the start, not discovered after the fact. A cold chain operator receives an alert the moment a temperature deviation occurs and cuts product loss significantly — that saving is quantifiable, comparable against TCO, and forms the basis of a credible ROI analysis. A machinery manufacturer uses sensor data for predictive maintenance, reducing unplanned downtime and production loss. In both cases, IoT is the instrument; the business model defines how the value that instrument creates is measured and captured. Without devices, the system doesn’t run. Without a business model, the system doesn’t grow.
Among mid-sized companies in Turkey, the pattern that keeps repeating is this: the project team selects the technology, builds the pilot, starts collecting data — but never defines upfront which decisions this data will change, and how much value those changed decisions will produce. Collecting data and using data are different activities. If a warehouse manager can see real-time shelf occupancy, what does that visibility actually do? If it optimizes order timing and reduces excess inventory costs, there is value. If it produces a dashboard that nobody acts on, there is none. This distinction rarely gets made during the pilot phase. When scaling becomes the conversation, the cost reality surfaces, and the project stalls.
One of the most consistent practical problems is that business units are kept out of the process. IoT projects are typically initiated by an IT department or an external consultant. Operations, finance, and sales come in late or not at all. In this structure, even a technically successful pilot fails to build a business case. When the CFO asks how much this system saves, the answer isn’t ready. Integration costs are another item that gets underestimated: connecting sensor data meaningfully to an existing ERP or accounting system, moving from file-based data transfer to a more real-time data flow, requires additional development work — and that cost rarely appears in the pilot budget.
For a manager evaluating an IoT investment, the critical question is this: after the pilot ends, what is the annual operating cost of this system, and is there a measurable savings or revenue item that covers it? If that question can’t be answered clearly, the pilot shouldn’t start. Technology selection is the second step; business model design is the first. Which decisions will change, how much value those changes will produce, and how that value will be measured — all of this needs to be written down before a single sensor is ordered. The pilot should test that framework, not just whether the hardware works. Otherwise, a successful pilot becomes nothing more than the opening chapter of a failed scaling story.
This article was originally written in Turkish by Gökhan MERCANOĞLU on February 3, 2014 and has been automatically translated into English and other languages using machine translation.