Open last month's connectivity invoice. Somewhere in it are two lines that tell the same story from opposite ends. A handful of SIMs went over their allowance and were charged for it. Several hundred used a fraction of theirs and were charged anyway.
You paid twice for the same problem: a per-device plan trying to predict the behaviour of a device it has never met.
Data pooling removes the prediction. Instead of buying an allowance per SIM, you buy one allowance for the fleet and every device draws from it.
The mechanics are unglamorous, which is the point.
Each SIM in the fleet has a nominal allowance, say 100MB a month. Pooling adds those allowances together into one bucket. A fleet of 1,000 SIMs at 100MB gives a 100GB pool. Every device then draws from the pool rather than from its own line.
In practice, one tracker sends 4MB and another sends 380MB, and neither triggers anything. Both come out of the same 100GB. Overage applies to the pool, not to the device, so you are billed once when total consumption exceeds the total allowance and not at all when it does not.
Two consequences follow. Unused headroom on quiet devices becomes usable capacity for busy ones. And per-SIM overage administration disappears from your month.
Inside one country, usage variation is the main argument for pooling. Across borders, three more arrive.
Usage patterns diverge by market. The same product installed in Norway and in Spain reports at different rates because installers configure it differently, because network conditions differ, and because customers use it differently. Per-country plans sized on a domestic pilot are wrong in both directions the moment you expand.
Roaming rates distort per-device economics. A device that crosses from its home market into a neighbouring one has the same job to do and a different cost profile. A pool sized on total consumption absorbs that. A per-device cap does not, and a device that hits its cap abroad stops reporting exactly when you have least visibility into why.
Fleet composition keeps changing. Devices ship, get installed late, sit in a warehouse for two months, get returned, get redeployed to another country. Managing an allowance per device against that churn is administration with no output. Managing one pool against it is a number on a dashboard.
The formula is average usage per SIM multiplied by the number of active SIMs. The work is in the first number.
Take real consumption from a representative period rather than from the device specification. The specification describes the reporting interval the firmware was designed around. Real devices retry, resend, log verbosely after a fault, and pull firmware updates nobody counted.
Then add for three things that show up later. Firmware updates over the air, which move a fleet's monthly total noticeably in the month they run. Growth, because you are adding devices during the contract, not after it. And fault behaviour, because a device with a flaky connection retries, and retries cost data.
Undersizing has a shared consequence worth naming plainly. If the pool runs dry, every SIM in it is affected until it is topped up, not the one device that overran. A pool socialises the headroom and it socialises the risk. That is a reason to set threshold alerts on the way up, not a reason to avoid pooling.
Pooling is a commercial and operational mechanism. It has clear edges, and knowing them prevents a disappointing quarter.
A pool is only as useful as the visibility over it. Three habits make the difference between pooling as a billing line and pooling as fleet control.
Set alert thresholds at 70% and 90% of pool consumption, and hold them against calendar position rather than absolute number. Hitting 70% on day 8 is a different event from hitting 70% on day 24.
Group SIMs by product line, by country, or by customer, so consumption is attributable. One pool for billing does not mean one undifferentiated blob for analysis.
Watch per-device outliers weekly. The top ten consumers in a pooled fleet are the early warning system for firmware faults, misconfiguration, and devices that were never meant to be online.
TheIXT Global Data Pool shares one allowance across every SIM in the fleet, across borders, on one invoice. Pascal Technologies runs a 5GB shared pool across its vessel fleet for exactly this reason: costs stay predictable while vessels move between countries.
Pool consumption, per-SIM usage, and threshold alerts sit in the IXT CMP in real time, rather than in a report that arrives 24 to 48 hours later as it does on several other platforms. That gap is what decides whether you catch a runaway device on the day or at month end.
Pool sizing above 100 SIMs is scoped with a person, because getting the average right is the whole exercise.
It is a plan structure where every SIM's data allowance is combined into one shared allowance for the whole fleet. Devices draw from the pool instead of from individual caps, so heavy users take up the headroom left by light ones.
Yes. With a provider offering global coverage on one subscription, the pool spans every country the fleet operates in rather than resetting at each border.
Every SIM in the pool is affected until it is topped up. Threshold alerts exist to make sure that never becomes a surprise.
Average real usage per SIM multiplied by active SIMs, with headroom added for firmware updates, fleet growth, and retry behaviour on faulty units.
The savings argument weakens. The administrative argument holds: one allowance, one invoice line, and no per-device overage reconciliation.
No. Keep per-SIM thresholds as an alerting mechanism. A pool protects the fleet from variation, not from a single malfunctioning device.
Pull 90 days of per-SIM consumption and sort it high to low. If the top decile is paying overage while the bottom half is under 30% utilised, you are funding both sides of the same gap. Ask us how it works for your deployment. Book a demo at ixt.io.