Detailed usage charges versus simpler charging models

July 9, 2008

If you are going to charge for things, one of the eternal questions is whether you should use detailed usage charges or simpler, 'flatter' ones. My personal thoughts run something like this:

If you have a fixed service that you're expanding slowly (if at all), detailed charges theoretically extract the maximum value for it. However, they do so at the cost of driving away users who don't like the unpredictability of their bills, and every so often you will have something go horribly wrong that sticks a user with an absurd bill (and sticks you with bad publicity if you try to make them pay it).

(In some situations this discouragement is fine, because you don't really want people to use the service in the first place and you're only offering it because of a historical accident. This is more or less how one part of the university wound up having probably the highest commercial timesharing rates in the world, before we got management approval to end the service entirely.)

Flatter rates give users more predictability and there's lots of evidence that they attract people as a result. They also simplify your capacity planning under suitable assumptions and thus your growth, because you basically sell capacity in advance; if you get a sudden surge of subscriptions, you can easily see how much more capacity you need. However, I think that overselling your capacity is easier (and certainly more common) with simpler charges, partly because new customers are being actively promised something and partly because you can get caught out if people's usage patterns change.

(For instance, our simple charges for disk space are partly based on how much backing things up costs us, which depends on how fast backed up data changes. If people started buying terabytes of backed up disk space that changed every day, we would have problems.)

Written on 09 July 2008.
« How to force Solaris to renumber network devices
Internet software decays and must be actively maintained »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jul 9 00:41:45 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.