3

I've ran into a problem trying to calculate prorating of a service. Hoping to get some help/hint from the community.

I apologize if this isn't the right place to ask this question - will appreciate help in finding the right StackExchange service.

Given:

  1. An online service that issues "licenses" that can be purchased for the time periods in multiples of 30 days/1 month (for simplicity, let's assume that all months have 30 days)
  2. "Base" subscription costs $15/month
  3. On top of base subscription there are also 20 "feature add-ons". Their price varies between $2 and $5 per month
  4. Customer is allowed to purchase "base" subscription without any add-ons
  5. Having paid the "base" $15, customer is allowed to add any "feature add-on" any time he desires without paying extra for it.

Details:

a. Item #5 above needs a bit of explanation. The idea there is to allow customers who are paying the base amount to "try out" any "feature add-on" without collecting more money from them.

Rationale:

"Customer X has already paid me $15 for 30days of service. Now, I will let him add a new "feature add-on" worth of $5/mo without sending him to shopping cart. However, I'll recalculate the expiry of the license based on $15+$5/mo rate. Thus the license would have fewer days until it expires".

Difficulty:

a. The newly added $5 add-on should itself be prorated. It is also possible that customer selects the amount of add-ons that would lead to the situation when the service would owe the customer.

b. There is a "cut-off" date that's determined by the amount the new add-ons cost after which moving license expiry date "to the left" (i.e. closer to current moment in time) would essentially make it expire immediately.

Questions:

  1. How do I calculate the updated expiry of a license based on the rationale above?
  2. How do I calculate the highest value of add-ons that can be selected without making license expire?
  • 1
    Computing this is the easy part. Producing proper invoices your accountant (and the accountants of your customers) are happy with is much trickier. – CodesInChaos Jan 20 '16 at 15:12
3

The easiest way to resolve this is to shift how you're defining the end of their license term.

Currently, I suspect you're using the natural approach of "User purchased base item for $N, so user has an expiration date of ..." In other words, the expiration date is determined at the time of purchase.

The challenge with that approach comes about when you want to allow clients to try features out for some period of time.

To fix that, you need to change your internal representation of how charges are accrued.

Pick a base unit of time, such as hours or days. From there, you can determine a rate per base unit of time. If we pick days as the base unit, and $15 for the basic license for 30 days, we end up with ~$0.50 per day.

From there, you'll need to have a slightly different equation for determining the remaining term within the license. You'll want something like:

var remTermInBaseTime = client.Balance / client.SelectedItems.BurnRate

That allows you to calculate the remaining amount of time in the base unit of time based upon the client's balance and selected feature burn rate. To provide a prediction of when the license will expire, you would add the remaining term to the current time.

Then, when a client selects additional features then all you have to do is update their burn rate and recalculate the remaining term. This also gracefully handles the case where a client tries feature X for a day and then removes the feature for whatever particular reason.

Ultimately this moves your clients to a per-feature subscription basis where they top off their balance as their funds dictate and you return with a reply of "this buys you N units of time" with your license. Whether or not you change your pricing to be reflected in the base units of time is dependent upon how your customers react to the change and what they appear to prefer to see.

One challenge with this approach is that some feature prices won't divide evenly into the base unit of time. For example, if you picked hours as the base unit, then you would end up with ~$0.020833 per hour for the base license. That could be handled with some rounding, or you could change the rates to be divisible by the number of base units of time that you pick.

| improve this answer | |
  • For extra fun the length of months varies, which is particularly ugly if the contract starts on the 31st of a month and the next month only has 30 days. And if you take DST switching even the length of a day. Handling that isn't pretty. – CodesInChaos Jan 20 '16 at 16:23
  • @CodesInChaos - Agreed, and I'm happy the OP excluded some of those concerns with "for simplicity, let's assume that all months have 30 days" – user53019 Jan 20 '16 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.