A connectivity subscription can turn a device sale into recurring revenue. Whether it earns a useful margin depends on what happens after checkout: activation failures, unusual data usage, replacement devices, unpaid renewals and support contacts all affect the cost to serve that customer.
If you sell wearables, cameras, POS terminals or other connected products, price the service against that full operating cycle. Start with measured device behavior, write down the customer’s service promise, and calculate contribution after the variable costs needed to keep that promise. A markup on the data plan alone leaves too much unexplained.
Choose the service promise before the allowance
A useful connectivity subscription for IoT devices starts with what the product must do. The data allowance follows from that requirement.
Use the device workload to decide what the offer should include. These are design questions, not recommended data allowances:
| Device workload | Cost risk to measure | Offer rule to decide |
|---|---|---|
| Wearable location, messaging or voice | Frequent updates and supported voice/message charges | Which functions and usage are included, and what triggers an upgrade |
| Camera with event uploads | Upload size and bursts after repeated events | Whether clips, image frequency or upload volume have an allowance |
| Camera with continuous video | Sustained traffic and recovery uploads | Whether the service supports this workload at the proposed price |
| POS terminal with cellular backup | A long primary-network outage plus software updates | What backup use includes and how excess usage is approved |
Do not put all four workloads into one allowance merely because they use cellular connectivity.
Measure a representative device group during normal operation, updates and failure recovery. Include background traffic and repeated connection attempts. Then obtain a written quote for the relevant devices, networks and markets. The IoT connectivity plan selection guide provides more context for comparing those requirements.
Define what happens when the allowance runs out: an approved top-up, an upgrade, throttling or a service limit. Confirm that the network and device support the chosen behavior. If the product depends on continued connectivity, the advertised promise and the exception policy must agree.
Also request prices for the states outside normal use. An offline unit does not necessarily stop generating charges. For example, Soracom distinguishes SIM subscription status from online/offline session status, and its suspension, renewal and reactivation fees vary by plan. That is a provider-specific example of why the contract matters; it is not a statement of Spenza’s fees.
Calculate contribution per subscriber-month
Use a recurring-service model that includes the costs your bundle creates. Keep the hardware sale, warranty and any device subsidy in a separate model so a strong device margin does not hide a weak service offer.
The following example assumes a hypothetical low-data subscription billed at $12 per active subscriber-month. It is not a quote, a customer result or a suitable price for every device category. Every figure is an invented planning assumption in US dollars.
| Item | Lower usage | Base case | Higher usage and support |
|---|---|---|---|
| Billed recurring revenue | $12.00 | $12.00 | $12.00 |
| Network service and data | $2.00 | $3.00 | $6.00 |
| Variable platform/service cost | $0.75 | $0.75 | $0.75 |
| Payment processing allocation | $0.65 | $0.65 | $0.65 |
| Expected support cost | $0.36 | $0.60 | $1.20 |
| Expected uncollected amount | $0.24 | $0.24 | $0.48 |
| Expected replacement service cost | $0.20 | $0.20 | $0.20 |
| Total modeled costs and loss | $4.20 | $5.44 | $9.28 |
| Monthly contribution | $7.80 | $6.56 | $2.72 |
| Contribution / billed revenue | 65.0% | 54.7% | 22.7% |
The support assumptions are 0.03, 0.05 and 0.10 contacts per subscriber-month, respectively, at $12 per contact. Expected collection loss is 2%, 2% and 4% of billed revenue. Replacement service cost assumes 0.01 events per subscriber-month at $20 of incremental service and logistics cost per event; hardware warranty costs remain outside this table.
Monthly contribution equals billed revenue minus the expected uncollected amount and the listed operating costs. The percentage uses billed revenue as its denominator. It is not company net profit or an accounting gross-margin measure. Fixed engineering, acquisition costs, taxes, financing and other overhead still need funding. Add any applicable supplier charge missing from this example.
At 1,000 subscribers, the base case produces $6,560 of modeled monthly contribution. The higher-usage case produces $2,720. The $3,840 difference comes from an additional $3,000 of network cost, $600 of support and $240 of collection loss. The subscription price has not changed.
Turn the model into an offer decision
Suppose you choose an illustrative 40% contribution target at the $12 monthly price. The cost-and-loss budget is $12 × (1 − 0.40) = $7.20. With base-case non-network costs of $2.44, network service must stay at or below $4.76 per subscriber-month to meet that target.
The higher-usage case fails this target: its $9.28 total exceeds the budget by $2.08. Before launch, test a higher price, a different allowance or a different supplier plan against the measured workload. Disclose any limits or top-up rules; do not solve the model by silently reducing the promised service. Recalculate the budget when payment losses or support costs change. Meeting a contribution target still leaves fixed overhead to fund.
Price the offer against more than its average month. A one-time activation or setup charge also needs its own cash-flow line. If you absorb it, recovery depends on customers staying long enough to generate sufficient contribution.
Make checkout explain the commitment
When you sell data plans with devices, the customer should understand both purchases before paying. Show the hardware charge and recurring connectivity charge separately, even when the checkout combines them.
The offer should make these details easy to find:
- The billing cadence and what starts the paid service period.
- The included allowance, supported use and markets.
- The behavior and charges after an allowance is exhausted.
- How to change, cancel or renew the service.
- What happens to the subscription when a device is returned or replaced.
Choose the activation trigger deliberately. Charging from shipment, first activation or another agreed event creates different obligations and costs. Record that choice in the customer terms and the operational workflow. A warehouse-held SIM, a shipped device and a functioning device should not be treated as interchangeable milestones.
Map the order to the customer, subscription and intended device or SIM. A second attempt at checkout or activation should not silently create another paid line.
Connect payment to working service
A payment confirmation proves a payment event occurred. It does not prove the device can communicate.
Track the path through separate checkpoints: order accepted, payment entitlement confirmed, connectivity provisioned, device connected and the relevant product function verified. Define who resolves a failure at each checkpoint and when a customer qualifies for a credit or refund under the offer’s terms.
The Spenza Partner API documentation describes asynchronous operations that return a transaction ID for status polling, plus an optional idempotency key for retried writes. Those mechanisms help an integration distinguish an accepted request from a completed operation and avoid repeating a write. A device-level connectivity check remains a separate acceptance test.
Payment events need similar care. Stripe documents duplicate and out-of-order webhook delivery. Process events safely, retrieve the current payment/subscription record where needed, and retain the identifiers required to reconcile the order. These are integration recommendations, not a claim that every connectivity platform implements the same workflow.
Account for replacements, failed payments and renewals
Budget lifecycle exceptions when designing the offer. The following controls protect the assumptions in the model; the operating runbook should specify the detailed actions and owners.
| Event | Cost to include | Control and pilot evidence |
|---|---|---|
| Device replacement | Shipping, profile/setup charges, support and permitted overlap | New device works; old service is handled through the supported process; supplier charges reconcile |
| Failed renewal | Collection loss, notices, retries and continued network charges | Disclosed recovery policy is applied; successful payment recovery is matched to working service |
| Plan change | Supplier cycle differences, prorations and credits | Customer charge and supplier effective date agree with the approved change |
| Annual renewal | Remaining service obligation, support and replacements | Expected cost of serving the full prepaid period is covered |
Do not assume an eSIM profile can be copied to a replacement device or that a failed invoice automatically suspends network service. Confirm supported actions and any grace period before selling the bundle. Review continuity obligations for safety-sensitive products with the responsible product and policy teams.
Stripe’s retry guidance distinguishes failures that need updated payment information. Its proration documentation explains why a credit adjustment is not automatically a refund. Use the applicable provider rules when calculating the retail offer and retain the supplier’s separate charging terms.
Make support cost visible
Track support contacts per active-device-month and the full cost of resolving each contact. Break out activation, payment, coverage, hardware and replacement issues so the team can see which changes would reduce repeated work.
Give customers one clear starting point for help, even when several suppliers must resolve the issue. A support record should connect the customer and device to the subscription, recent payment and provisioning status. That prevents a billing problem from being investigated as a radio fault.
In the illustrative base case, 50 contacts across 1,000 subscriber-months at $12 each cost $600. Doubling the contact rate adds another $600 without changing revenue. Measure those inputs in the pilot instead of assuming support will remain negligible as sales grow.
What the Angel Watch example demonstrates
The published Angel Watch case study describes region-specific mobile plans suited to smartwatch usage, Shopify-based plan bundling and usage analytics.
Two choices matter for a device business: plans designed around smartwatch use, and a purchase journey that lets the customer buy the device and its connectivity through the Shopify store. Apply that reasoning to your product before copying a generic phone plan or adding a second checkout. The case supports those commercial design choices; it does not report the contribution margin in this article’s illustrative model.
Pilot the complete bundle before scaling
Require a reviewable evidence pack before approving launch:
- Supplier quote: document eligible devices and markets, every chargeable state, allowance behavior and effective dates.
- Usage sample and cost model: record normal operation, updates and adverse usage; show whether each scenario meets the chosen contribution target.
- Checkout terms and activation record: show the recurring commitment and service-start trigger, then prove purchase, provisioning and device use reconcile.
- Test replacement: confirm the new device works, the customer agreement stays correct and the old line stops accruing unintended charges.
- Test renewal and cancellation: check failed payment, recovery, credits and the network action required by the agreed policy.
- Reconciled pilot invoice: compare collections, supplier charges and support effort for the same device group and period. Explain deviations before expanding the offer.
Scale when those checks support the price and service promise. To evaluate the bundle with Spenza, bring your device requirements, target markets and cost assumptions to the IoT connectivity team, and agree the supported workflows before committing to the offer.
FAQs
Prepared by Spenza, a connectivity management and telecom platform provider. Contact the Spenza team for product-scope questions.
