Cloud service providers have a nasty habit of focusing on the technology that they offer to their customers without considering how to solve the problems of billing for the technology until after it is in place. At best, this results in a nasty surprise for the accounts department. At worst, it results in the inability to monetize a new product.

One main problem area is when cloud service providers underestimate the likely complexity of their product catalog. They often think they are selling disks, servers and networks, and wonder what is the challenge with having three products. In our experience, very few customers end up with such simple set ups.


Here are five reasons why:

1. Cloud service providers often want to make some products available to some customers, and other products available to other customers. Those might be the same technical products, but sold at different prices or with different billing plans. We support this in Flexiant Cloud Orchestrator by distinguishing between a product and a product offer. Our tagging system allows products to be made available to groups of customers.

 2. Whilst some providers are happy with ‘we charge $x per gigabyte per hour’, others offer specific configurations of machine, and have pricing that may not be entirely linear. For instance, some service providers might be happy for the customer to configure any amount of RAM on their virtual machine from 512MB to 16GB, charging at $0.01 per GB per hour; but another might want to offer specific combinations of RAM and CPU, discounting the larger machines appropriately. This increases the size of the product catalog. We can cope with both possibilities by using a system called ‘configured values’, which can be nailed down by the licensee either when the product offers are created, or left to the end user to configure.

  1. Cloud service providers frequently have different groups of customers that are billed in different ways. For instance, they may bill cloud customers by hourly usage, and VPS customers with some element of monthly billing. It is important that a billing system can group customers and support different mechanisms of billing depending on the commercial imperatives. We handle this by allowing customer level billing as well as permitting resource level billing.
  1. Service providers often use channels to get to market. There is thus a requirement for the billing system to be multi-tenant, as each reseller needs to manage its own customers without seeing the customers of other resellers. However, operating a ‘virtual billing system’ for each reseller is not extensive enough, as this would require each reseller to set its product catalog up from scratch. Your billing system needs to support some form of master product catalog which allows you to make system wide changes and, where appropriate, for these to be reflected in the product catalogs of your resellers. With our product, reseller creation can be lightweight that each reseller can rely solely on the central product catalog.
  1. Products can be retired and replaced. But that can still leave you with customers running old products. There is a balance to be struck in this situation between your product catalog including many legacy products (which may produce more margin as prices tend to drop) and having a tidy product catalog, particularly as the process of tidying may result in decreased margin, attrition (as customers are reminded of products they forgot they had bought) and customer irritation. We allow retired products either to be substituted or to run on but be unavailable to new subscribers.


All of these, unless considered carefully, lead to product sprawl. It is an easy trap to fall into, and we completely rewrote our product handling in Flexiant Cloud Orchestrator to avoid it. Read our latest whitepaper on cloud billing which highlights common pitfalls in cloud billing systems, and identifying how Flexiant Cloud Orchestrator meets these challenges. 

Tags: , , , , , , , , , , ,