How do you track firmware update costs for billing: usage-based or inventory-based models?

IOT Cumulocity IoT
, , , , , , , ,
1

Our company provides IoT device management services using Cumulocity 1020.x, and we’re redesigning how we charge customers for firmware update services. Currently we use a flat monthly fee per device, but this doesn’t reflect actual usage patterns. Some customers update firmware monthly while others go 6-12 months between updates.

I’m exploring two approaches: usage-based (charge per firmware update operation) versus inventory-based (charge based on firmware versions stored in repository). Usage-based seems fairer but harder to predict revenue. Inventory-based is simpler but doesn’t reflect actual customer activity. Both models affect customer transparency and our revenue predictability differently.

How are other Cumulocity service providers handling firmware update billing? What metrics do you track, and how do you balance customer fairness with predictable revenue streams?

2

I’ve consulted with several IoT platforms on pricing models, and firmware updates are always contentious. Here’s my analysis of the three key considerations:

Usage-Based vs Inventory-Based Models: Usage-based aligns with customer value but creates revenue volatility. Customers update firmware in response to security vulnerabilities or feature needs, which are unpredictable. Inventory-based provides stable revenue but feels unfair to customers who maintain large firmware libraries “just in case” but rarely deploy them.

Best practice: Tiered usage-based with volume discounts. Charge per successful deployment but offer graduated pricing (first 100 updates/month at $X, next 400 at reduced rate, etc.). This balances fairness with predictability and incentivizes customers to consolidate updates into planned maintenance windows.

Customer Transparency: Transparency is non-negotiable in modern SaaS. Provide a billing dashboard showing:

  • Real-time firmware operation counts
  • Month-to-date costs with projections
  • Breakdown by device group or customer segment
  • Comparison to previous periods

Customers tolerate variable costs if they can monitor and predict them. Cumulocity’s analytics can feed this data through custom dashboards or integrate with billing systems via REST API.

Revenue Predictability: For financial stability, consider commitment-based pricing. Customers commit to minimum update volumes annually (e.g., 5000 firmware deployments) at a discounted rate. Overages charged at standard rates. This provides baseline ARR while capturing upside from high-usage periods.

Alternatively, implement “update credits” - customers purchase credit bundles (e.g., 1000 updates for $X) that roll over monthly. Unused credits expire after 12 months. This shifts revenue recognition forward while giving customers flexibility.

Implementation Recommendation: Start with simplified usage-based (per successful deployment) and add complexity based on customer feedback. Track these metrics in Cumulocity:

  • Firmware operations by status (success/failure/pending)
  • Data transfer volume for firmware binaries
  • Device downtime during updates
  • Rollback operations

Use measurement API to capture these as custom measurements, then aggregate monthly for billing. Build a buffer period (e.g., first 3 months at flat rate) to gather data before transitioning customers to usage-based pricing. This avoids surprising customers with unexpected bills while you calibrate pricing tiers.

The key is making the model understandable. Customers should be able to predict their bill within 20% accuracy at any point in the month.

3

The hybrid model is interesting. How do you handle bulk operations in your usage tracking? When a customer updates 500 devices in a single bulk operation, do you count that as 500 billable events or one bulk operation? Also, for the threshold approach, how did you determine that 2 updates per year was the right baseline? Our customer base ranges from industrial IoT with quarterly updates to consumer devices with weekly patches.

4

Consider the operational complexity too. Inventory-based billing is simpler to implement - just count firmware objects in the repository monthly. Usage-based requires real-time metering, handling edge cases like partial failures, and reconciling bulk operations. We started with inventory-based for simplicity, but customers complained they were paying for old firmware versions they never used. Customer satisfaction matters more than implementation ease.

5

From a product perspective, usage-based pricing aligns better with customer value. Customers who update frequently are likely managing critical infrastructure and see more value from the service. However, you need good metering infrastructure. We use Cumulocity’s measurement API to track firmware operations and aggregate monthly. The challenge is explaining variable costs to customers who prefer predictable bills.

6

Revenue predictability is crucial for financial planning. We use a hybrid model: base fee per device plus usage charges above a threshold. Each customer gets 2 firmware updates per device per year included, then pay per update beyond that. This provides baseline recurring revenue while capturing high-usage customers. The threshold incentivizes customers to consolidate updates rather than pushing small changes frequently.

7

We switched from flat-rate to usage-based last year and it’s been mostly positive. We charge per successful firmware update operation, not per attempt. This required integrating with Cumulocity’s audit logs to track completed operations. The key is defining what counts as billable - do failed updates count? What about rollbacks? We only bill successful deployments, which customers appreciate for transparency.