IoT fleet management: 5 costly connectivity sourcing mistakes
Taavi Jõgeva
Connectivity is one of the most consequential decisions a fleet management OEM makes — and one of the most misunderstood. By the time most teams start comparing IoT connectivity solutions, they have often already made component choices that will constrain their global ambitions for the entire lifetime of the device.
The pattern is consistent. Across hundreds of fleet deployments, the connectivity failures we see rarely trace back to a bad network or a bad SIM. They trace back to a handful of avoidable decisions made early.
Here are the five that cost the most, and how to catch them before they become expensive to reverse.
1. Choosing the cellular module last
The single most disruptive error in fleet connectivity happens at the hardware stage, not the connectivity stage. The cellular module soldered into your device determines which networks, bands, and technologies it can physically connect to. No connectivity provider, however good, can make a device reach a network its hardware doesn't support.
The trap we see regularly: an OEM with global deployment targets sources all its components, gets ready for production, and treats connectivity as the last piece. Their target markets include the US, Asia, and Africa — but their chosen module is a regional European one that often can't reliably connect in any of them. At that point the only options are absorbing the component loss or shipping into markets the hardware can't serve. Both were avoidable with earlier validation.
Low-power modules carry a similar risk. NB-IoT and LTE-M are chosen for their cost and energy efficiency, but they aren't deployed everywhere — much of Africa, the Middle East, and parts of Asia haven't rolled out that infrastructure. A device built on LPWAN-only hardware can work perfectly in Western Europe and fail entirely in the markets where you most need to grow.
The fix: validate module selection against your three-to-five-year deployment map before you buy components, and confirm band and technology availability in every target market — not just today's.
2. Underestimating permanent roaming restrictions
A global SIM that roams across carriers solves the basic coverage problem, but it runs into a wall that's often discovered far too late: several markets regulate how long a foreign SIM can operate on their networks in a roaming state. Brazil, India, and Turkey are the ones that catch teams out most often.
If any of these markets are on your roadmap, your fleet management connectivity strategy has to account for them from the start, not as an afterthought once devices are already in the field. The workable answers all come down to the same thing — a way to put devices on local connectivity in those markets instead of leaving them roaming — so the real question is how a vendor delivers that.
The fix: ask directly how a vendor handles permanent-roaming-restricted markets like Brazil, India, and Turkey, and confirm the answer before you commit deployment volume there.
3. Sourcing your connectivity stack from multiple vendors
As OEMs start evaluating eSIM options, a tempting pattern emerges: source the SIM hardware from one supplier, bootstrap connectivity from another, and carrier profiles from a third. On paper it looks like flexibility. In practice it creates integration complexity and diffuses accountability.
When a profile fails to download or a device won't connect in a new market, the question of which vendor is responsible becomes very hard to answer — and each vendor's support team points to the others. The integration effort between components that were never designed to work together is routinely underestimated, and the savings from buying piece by piece are usually eaten up by the overhead of managing multiple contracts and relationships.
There's a related misconception worth naming: that any eSIM can download any profile from any provider. Technically it sometimes can — but a profile that isn't integrated with your connectivity management platform is effectively unmanaged. You lose the ability to monitor usage, run diagnostics, or automate state changes across the fleet. For hundreds or thousands of devices, that isn't a workable model.
The fix: favour a turnkey model where the eSIM, profile management, and management platform come from one accountable vendor — and if you do want to mix components, understand that trade-off explicitly before committing.
4. Treating connectivity as a deployment-only cost
Per-megabyte pricing is the number most teams focus on when comparing providers. It's also one of the least useful in isolation, because the costs that quietly add up sit elsewhere — and most of them land during production, long before a device generates any value.
Activating every SIM at full rate from day one of manufacturing means paying for connectivity while devices sit in a warehouse or in transit. Across a large production run, that's real money spent before any device generates value. A provider with proper SIM lifecycle management avoids it: a test state gives you a small, low-cost data allowance for end-of-line quality control and IMEI pairing, and an offline state keeps devices registered but uncharged until they're deployed. Handled well, that removes the production-phase connectivity cost almost entirely — before you've even started negotiating per-MB rates.
There's also a production-line detail worth knowing. When thousands of devices finish their end-of-line checks at once, all their SIMs try to register on the nearest tower simultaneously — a sudden spike that can overwhelm the local infrastructure and cause registration failures even when the SIMs and the network are both working normally. If you manufacture at scale, ask whether your provider's platform can stagger activations to avoid it.
The fix: evaluate total cost of ownership — component cost, network registration fees, production-phase activation, contract lock-in, and future migration — not the per-MB rate on its own.
5. Signing a multi-year contract before running a real pilot
Scalability comes up in almost every vendor conversation, and it's one of the hardest things to judge on paper. Every vendor reports strong uptime and describes a solid infrastructure in an RFP. The only way to know whether one can actually deliver for your specific deployment is to test it in real conditions.
Committing to a multi-year contract before a meaningful proof of concept transfers all the risk to you. Anything you discover after signing — a coverage gap, a support problem, a platform limitation — has to be resolved inside the terms of that contract, usually without leverage.
A proper pilot mirrors real production and deployment, not just a connectivity test. Run the full production exercise — component sourcing, IMEI pairing, SIM state management, quality control — on a few hundred units, deploy them with real customers for three to six months, and evaluate the whole relationship: connectivity uptime, API consistency, support response, and how quickly issues actually get resolved.
The fix: run a structured pilot before you commit at scale, and treat how the vendor handles problems as seriously as whether the devices connect.
Choosing IoT solutions for fleet management
The teams who get this right treat connectivity as a strategic capability designed in from the beginning, not a component sourced at the end. They match hardware to their geographic ambitions, structure production to manage cost from day one, run real pilots before committing, and choose vendors on the complete relationship — platform, support, and commercial flexibility — rather than the per-MB rate alone.
When you're comparing IoT solutions for fleet management, the goal is to walk into a vendor conversation knowing what you need to learn — ideally with a structured evaluation checklist in hand — not just what price you want to hear.
Want the full framework? Our guide, How to Source Connectivity for Fleet Management OEMs, walks through every stage — hardware selection, production logistics, eSIM standards, total cost of ownership, and a vendor evaluation checklist you can take straight into your next RFP.
.avif)
.avif)
