Link between Subscription parameters amount for recurring fee and usage-based amount to be billed

[tvc_em]

Dear Experts, 

Our customer sells subscriptions as the example below:

Product: ABC
Included service: 200 API calls per truck
Price: 50€ per truck per month + 2€ per additional API call

A pooling principle is applied where:

- if trucks = 2  ==> API calls included = 400
If at the end of the month the total consumption is > 400 -> unit price is applied for as of the 401th API call.

- if trucks = 4 ==> API calls included = 800
If at the end of the month the total consumption is > 800 -> unit price is applied for as of the 801th API call.

As a first thought, I would create a product with a recurring rate element for the monthly fee based on the number of trucks, plus a consumption-based rate element for the additional API calls with a pricing scale ex. truck : 1 -> pricin scale: 0-200ea = 0€ and as of 201ea = 2€ each.

This setup would easily work if the number of trucks would remain always the same, unfortunately this is not the case as the number can both increase and decrease over time.
While the update of the number of trucks is simply solved by updating the number of the subscription parameter (either manually or via API from the external system), updating every time the scale in the lookup table data doesn't seem like a safe/sustainable solution.

Is there a more efficient way to achieve the described scenario? 

Thank you very much in advance.

[CarstenJ]

Hi,
the approach with two charges seems to be the right one. 
However, as charges are rated independently of each other, the subscription parameter representing the quantity of the recurring charge is not available in the pricing of the usage-based charge.

So the first problem is to get the number of trucks into the pricing call to rate API Calls. This is probably only possible by adding a product configuration field in the subscription and store the number of trucks redundant in this field. But with this, you can use the pricing field mapping to use it in the pricing tree which calculates price for API Calls.

Second problem is the varying number of trucks which relates to the number of included API calls.
The idea would be to relate the number of API Calls to the number of trucks, maybe by a simple division (average calls per truck)?
2 Trucks, 700 API calls -> in average 350 calls
5 Trucks, 2500 API call -> in average 500 calls
That should allow you to keep the ranges stable. 

Best
Carsten

[tvc_em]

Dear Carsten, thank you very much for the quick and useful feedback. I understand the idea of repeating the number of trucks as a configuration attribute, on the other hand I'm not sure I understand the second part of your suggestion. Considering that the first 200 API calls per truck are covered by the monthly recurring, the volume pricing for the usage-based element seems to me necessary, as a consequence the result of the calculation based on nr of trucks/api calls should somehow influence the lookup table data which doesn't seems possible to me - ex. for 2 trucks, from 0 to 400 api calls have fixed price 0€ / from 401 is 2€/ea, but for 4 trucks this becomes from 0 to 800 api call = 0€ and from 801 is 2€ ea. Could you please clarify a bit more how you think this could be achieved? Thank you very much in advance and have a nice day.

[CarstenJ]

The price model would be the one for a single truck, but a tier:
from 0 to 200 'normalized' API calls - 0 €
beyond: 2€ / EA

Example: 2 trucks, 700 API calls -> 350 'normalized API calls'
Pricing with a tier: 200 calls -> 0 € + 150 calls * 2€ = 300 €

There's also the alternative to normalize and subtract the included quantity in a formula (calls / trucks - included calls), and use the result in a volume price model. 
Then you need to ensure that no negative quantities are calculated (can be done with the suitable quantity operator).