Tiered discounts based on number of subscription

[E Fernandez]

Hello everyone

 

We would appreciate if anyone can give new ideas.

 

We need to find a way of implementing a tiered discount model based on number of subscriptions.

 

This model could have two flavors:

 

1. Absolute: Count number of subscriptions for an account and based on the tier that number are apply a discount Total Recurrent Fees * Discount (ideally in %).
2. Categorized: Similar to the previous one but the subscriptions are categorized (custom field) and the calculations and discounts are done by a category.

 

There will be around millions of subscriptions per account. Each subscription will have only installation fees and monthly recurrent fees.

 

We thought on several approachs:

• Usage based on Capabilities. This approach will impact on re-inject every month the #subscriptions as capacity to the system. Is there a point to automate this based on BCD or something similar?

This would be a good option for flavor 1 but in the second flavor There will be around 300 categories, so we think that implement subscription categories as a specific plans maybe is not a good decision … too many catalog updates maybe …

• Invoice Plugin. We are worried for a plugin with million of recurrent fees in a single invoice…. Does anyone has experience about if this is feasible?
• Any other?

 

Any idea of how to take an approach of it? Some piece of advice? 

 

Thank you very much in advance for your help.

[stephane brossier]

From reading through your request, there are 2 different things to consider:

• The scalability aspect: Millions of  recurrent fees (subscriptions?) is indeed a very large number. I don't know enough about your business case and why somebody would be invoiced for millions of things? Perhaps, it's a legit case, perhaps you have the wrong model?
• The ability to discount based on some very custom scenarios: Using the various plugin apis (e.g invoice plugin) to write that custom logic is probably the correct approach.

Stéphane

--
You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/ffbef3cd-fcee-436f-8422-27a6575a5eadn%40googlegroups.com.

[E Fernandez]

Thank you very much Stéphane for your answer.

We are in a B2B2X business model. We are providing individual services to a X (individual or company, from now on Final Customer) on behalf another company (from now on Our Customer.

We had negotiated a contract to charge based on a monthly fee per Final Customer and some unusual activities that will be charge as OTC (One Time Charge).

That is why Our Customers can have millions of subscriptions. 

We thought the possibility of creating an external system to be able to give Our Customers access to the up to date services list, and create a PxQ invoice (Monthly Service x Q final customers = ....) in killbill. But creating one subscription per final customer saves us from creating this system.

Are we making a bad design from your point of view?

Thank you very much for your attention!

[stephane brossier]

It's hard to say in the absolute, but scaling to millions of subscriptions/user may prove challenging. I would recommend you invest in doing a POC and try to simulate some of this load to see if 1/ based on your configuration 2/ hardware 3/ specific use cases, how the system behaves. It would at least make this discussion less abstract.

Best,

Stéphane

To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/CA%2ByUqfRXC8PPWD39OpREfsfAk1DB1BC3AscwTyn4OdMFG0SL6Q%40mail.gmail.com.