As companies building and operating IoT services grow, the nature of the business changes in ways that are not always obvious at the outset.
Early progress is usually driven by product capability: whether devices perform as expected, whether software delivers usable insight, whether deployments can be completed reliably. Connectivity sits alongside these concerns as a practical requirement — necessary, but largely interchangeable.
As deployments increase in number, geography, and commercial importance, that framing becomes harder to sustain. What began as a product-led effort becomes an operational service, with ongoing commitments rather than discrete deliveries. At that point, constraints stop being purely technical and start to show up in the structure of the business itself.
One of the most persistent tensions at this stage sits between responsibility and control.
In a service business, accountability compounds over time.
Customers experience the service as a whole. Contracts, SLAs, renewals, and reputation are shaped by outcomes, not by how responsibilities are split behind the scenes. When something degrades, the distinction between hardware, software, connectivity, and third-party suppliers is largely irrelevant to the customer.
As services grow, the provider increasingly carries responsibility for:
That responsibility often expands faster than direct influence over every dependency that contributes to those outcomes.
If you’re already running IoT services with live estates and customer commitments, you'll likely have felt this when it comes to connectivity.
In many services, connectivity decisions are made early, delegated to customers, or inherited through standard commercial arrangements. At the outset, this is usually a pragmatic choice. It reduces friction, avoids early complexity, and allows teams to focus on proving the core service.
As services mature, the implications of those early choices become harder to ignore.
Misalignment between responsibility and control rarely presents as a single failure or breaking point. Instead, it shows up through everyday operational and commercial pressure.
Support teams spend more time investigating issues they cannot directly diagnose or resolve. Commercial teams introduce caveats into proposals to manage uncertainty. Product teams hesitate to evolve architectures because downstream consequences are difficult to predict. Finance teams see margins tighten without a single obvious cause.
Taken individually, these are familiar operational challenges. Viewed together, they point to a structural issue: a dependency that sits outside the service boundary, while accountability for outcomes remains firmly inside it.
At scale, this becomes less about the quality of connectivity itself and more about how the service is designed to absorb variability and change.
It's natural to look to tooling as a way to address this tension — adding dashboards, APIs, or management layers to improve visibility.
Those capabilities have value, but they don’t resolve the underlying question of ownership. Tools work best once there is clarity about how connectivity is governed within the service: whether it's actively managed as part of delivery or treated as an external factor to be accommodated.
Without revisiting that structural decision, additional tooling tends to improve insight without materially changing leverage. Teams can see more clearly what is happening, while still lacking the ability to shape outcomes in line with the responsibility they carry.
Teams operating at scale often approach the issue from a different angle.
Rather than focusing on how to manage connectivity more efficiently, they look at how responsibility, control, and economics are distributed across the service as a whole.
That leads to practical questions such as:
Connectivity typically features in these discussions, not because it's unusually complex, but because it affects so many second-order outcomes: deployment timelines, support load, cost variability, and customer confidence.
Treating connectivity as part of service design does not imply running networks or becoming a connectivity specialist. It involves making deliberate choices about how connectivity is governed, rather than allowing it to sit outside the service boundary by default.
In organisations that have addressed this, the shift is visible in operational and commercial decisions rather than in messaging.
That often includes:
These aren’t really technical upgrades, they’re choices about how the service is structured and how risk is distributed across the business.
At smaller scales, misalignment between responsibility and control can be managed informally. Teams compensate. Customers are flexible. Exceptions are tolerated.
As services grow, those coping mechanisms stop holding. Complexity increases faster than headcount. Exceptions harden into precedent. Marginal inefficiencies become material.
At that point, the question shifts from whether the service works to whether it can continue to evolve without accumulating friction that slows growth or erodes confidence.
Encountering this stage isn't a sign of failure. It reflects the limits of an operating model designed for an earlier phase of the business.
Across the IoT market, organisations that sustain growth over time tend to converge on similar conclusions.
They recognise that accountability without influence creates instability. They adjust service boundaries so that the dependencies they are held responsible for are also those they can meaningfully shape.
Connectivity often becomes part of that adjustment, not because it's new, but because its role within the service has changed.
Approaching connectivity as a service-design concern reflects a broader shift: from delivering solutions to running services, and from optimising for speed to optimising for durability.
That shift increasingly differentiates businesses that scale from those that stall.
Recognising the need to realign responsibility and control is the easy part. Acting on it can be harder.
Pulling connectivity inside the service boundary can look, on the surface, like a significant increase in complexity. It raises questions about operational load, support responsibility, commercial risk, and internal capability:
For teams already focused on running and growing a service, this can feel like trading one set of problems for another.
So that’s where we come in.
At Pangea, we provide a connectivity platform and operating model designed for companies building and running IoT services.
The platform allows solution providers to order, provision, and manage cellular IoT connectivity at scale, with visibility and diagnostics that support service operations. It enables teams to monitor usage and performance across live estates, diagnose issues in context, and apply rules and controls that reflect how their service is sold and supported.
Alongside the platform, we work with solution providers on how connectivity is applied within their service model. This includes decisions about where connectivity sits within the service boundary, how it's bundled commercially, how responsibility is shared, and how support processes align with customer commitments. It also includes ensuring connectivity can change over time without forcing contractual or architectural resets.
Taken together, this allows solution providers to move towards provider-governed connectivity, clearer service boundaries, more predictable operations, and commercial models that support recurring revenue — without taking on unnecessary operational burden or telco complexity.
In practice, that means operating connectivity with a level of control and visibility that matches the responsibility already carried by the service, while keeping focus on the product and outcomes that differentiate the business.
That combination — platform capability applied through real service design decisions — is what allows connectivity to support growth rather than complicate it.
_white.svg)
