Taking care of monetization
“Development of a monetization feature in software takes time and care, because it interconnects with nearly every aspect of the operations of an organization, from the bottom of the stack to the top. It drives revenue and it's the heart of your business.”
Published on 3 June 2020
Does your finance team get mired in manual processes every month? Is your goal to automate billing, but it’s complicated by multiple integration issues? Do you spend too much time figuring out if the bills you're about to send to your customers are accurate? Yeah, maximizing revenue is difficult! We've been there. As a managed services provider, CloudOps has faced our own challenges, and we know the obstacles that other service providers experience when monetizing their cloud and network services portfolios.
When we decided to build CloudMC, we wanted to create a cloud services portal to serve the needs of our service provider customers, with monetization at the centre of it. Because of our plugin-based design, we chose to put the pricing information at the control of the system administrator who would be configuring the service connection.
It was simple and straightforward. The plugin designer was responsible for providing a list to CloudMC of all the resources exposed by the plugin. In turn, CloudMC administrators were presented this list on the Manage Pricings page, where they could assign a price per unit to each resource.
The old Manage Pricings page
The Cost Estimator gives real-time pricing when provisioning or resizing resources
Similarly, CloudMC allowed administrators to define resource commitments with that same list. If a customer would commit to purchasing a minimum quantity of a resource every month, that minimum quantity could be offered at a different price from the normal utility (pay-per-use) rates.
With these pricings, CloudMC was able to produce clear usage reports with graphs and total charges. Users could see real-time pricing when provisioning resources with the Cost Estimator. It was pretty great! The pricing system was a critical part of enabling our customers to achieve their monetization goals.
Over time, it became clear that this design had certain limitations. The responsibility for managing prices fell onto the technical team. Products were in static categories determined by the plugin. Related products could not be grouped together. Only a single, system-wide currency was supported. The code for the plugin itself would require modifications to support any new product introduced by the service.
We saw that there would be deeper problems, too. Things go wrong all the time. Things we never plan for. What if there was a human error in the pricing? Or even worse, what if there was an error in the data being pulled from the remote service? Errors like these would lead to incorrect charges being billed to the customer. Manual intervention would be required in these situations.
A portion of the Service Usage report
As CloudMC matured, we realized that we had an opportunity for growth. Our pricing system was a first edition. It was the moment to design and build the second edition. Development of a monetization feature in software takes time and care, because it interconnects with nearly every aspect of the operations of an organization, from the bottom of the stack to the top. It drives revenue and it's the heart of your business.
For over two years now, we've been working on a completely new monetization engine to address the issues we identified, to expand on existing features such as resource commitments, and to add important new functionality such as discounts and credits, tiered pricing, and the ability to roll back past usage data. We’ve decoupled the product definition from the price, enabling us to support multiple concurrent pricing models, in multiple currencies if desired. And new support for calculating sales tax on your product offerings ensures compliance with the tax laws of the jurisdictions where you do business.
We've integrated monetization with our RBAC (role-based access control) system, which is customizable and authorizes a team of administrators to manage multiple organizations. Products are defined not by the plugin designer, but by a finance administrator who is given exactly the set of privileges needed to accomplish their tasks.
Some of the permissions that can be granted for monetization
Products live inside product catalogs, and are organized into product categories inside the catalog. Your finance team will work with your technical team to choose the raw data that represents the desired products, and then define transformations, filters, and proper units for the data, as needed. Here’s a quick diagram of the relationships between some of the important new components in the CloudMC monetization system:
Relationships between important monetization components
Product catalogs and pricings are the central concepts in the monetization engine. Your finance team uses (and re-uses!) product catalogs and pricings to build various pricing packages with the rates, discounts, credits, taxes, and currencies you need for your business. It’s worth emphasizing the re-use aspect of the system. By connecting pricings with product catalogs instead of products, we gain much greater flexibility in reusing product definitions with multiple pricing packages.
Managing categories on the Edit Product Catalog page
Those same categories on an actual customer invoice
And there is a direct line between the product catalog and the user experience. Each product catalog is built from a single service connection, or type of service connection, and pricings can use products from multiple catalogs. You can group your products logically and intuitively for your customers based on what services they are consuming. Invoices will have line items detailing resource consumption, and the line items will be grouped together on the invoice in the product categories you’ve defined.
One of the new features we're most excited about is the ability to roll back past usage data and reprocess it, or even recollect the data if needed. There are many scenarios that can take advantage of this feature, saving you time, and improving the experience your customers have with your services.
Imagine that your sales team offers a particular discount to a customer on a given product, but the finance team doesn't get the memo, so the discount doesn't get assigned to that customer. At the end of the billing cycle, CloudMC generates your invoices. We have introduced a review period, during which invoices are complete but have not been issued to a customer. A finance administrator can take the time to review each invoice to make sure there's nothing unexpected. Let's say that during this stage, the forgotten discount is discovered by the finance team. The invoice can be flagged, preventing it from being issued. The discount can then be applied retroactively to the customer, fixing the oversight. CloudMC will automatically roll back the billing cycle, and when it is finished reprocessing, it will produce an invoice with the correct discount calculated.
Another possible scenario: your service provider encounters some sort of problem, and is unable to publish the usage data. The problem goes undetected for several days. Meanwhile, your customers are using the service and incurring the expected charges. What happens here? Again, there's nothing to panic about. After the service provider has fixed their problem, your finance team can log into CloudMC, and with a couple of clicks they can launch a manual rollback from a given date, say, the first day the data went missing. CloudMC will roll back to that date, recollect all the usage records from the service, and then reprocess the records transparently to the users. When the reprocessing is complete, reports and pending invoices will immediately reflect the updated information, and any needed adjustments for individual organizations will be made automatically.
Another possible scenario is where certain changes to a product definition could trigger an automatic rollback in order to keep pricing consistent with the configuration. For example, modifying either the transformation or the filter of this product would have a significant impact on how charges are calculated, and would trigger CloudMC to reprocess the relevant data:
Modifying the transformation or the filter on this product could trigger an automatic rollback
These are only a few examples of the power of the CloudMC monetization engine. We are really excited about it! We've committed the resources to building these features because we know the pain that managed service providers experience on a daily and monthly basis. Using the lessons we've learned, we firmly believe we are uniquely positioned to focus on enabling your business to take care of monetization and to maximize revenue from your cloud services portfolio, with CloudMC.
