z commerce-for-the-cloud-blueprint

© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited.

Blueprint for the Cloud A guide to metering, pricing, and billing for cloud commerce

June 2010

Zuora Blueprint for the Cloud

© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. of 19

Table of Contents

1 OVERVIEW ........................................................................................................................4

2 PRICING AND PACKAGING.............................................................................................4 2.1 Overview.......................................................................................................................... 4 2.2 One-Time Charges .......................................................................................................... 4 2.3 Recurring Charges .......................................................................................................... 4 2.4 Usage-Based Charges .................................................................................................... 5 2.5 On Demand Pricing ......................................................................................................... 5 2.6 Reservation Pricing ......................................................................................................... 5 2.7 Location-Based Pricing.................................................................................................... 6 2.8 Off-Peak Pricing .............................................................................................................. 6 2.9 Free Trials ....................................................................................................................... 6 2.10 Promotions ................................................................................................................... 6 2.11 Packaging and Bundling .............................................................................................. 6

3 USAGE PROCESSING......................................................................................................7 3.1 Overview.......................................................................................................................... 7 3.2 Metering........................................................................................................................... 7 3.3 Usage Collection and Integration .................................................................................... 7 3.4 Rating .............................................................................................................................. 8

4 BILLING .............................................................................................................................8 4.1 Overview.......................................................................................................................... 8 4.2 Creating Invoices............................................................................................................. 8 4.3 Adjustments..................................................................................................................... 8 4.4 Scheduled Bill Runs ........................................................................................................ 9 4.5 Ad-Hoc Bill Runs ............................................................................................................. 9 4.6 Billing Approvals .............................................................................................................. 9 4.7 Batching........................................................................................................................... 9 4.8 Multi-Channel Delivery .................................................................................................... 9

5 PAYMENTS........................................................................................................................9 5.1 Overview.......................................................................................................................... 9 5.1 Multiple Payment Types ................................................................................................ 10 5.2 Ad-Hoc Payments.......................................................................................................... 10 5.3 Scheduled Payment Runs ............................................................................................. 10 5.4 Payment Gateway Integration ....................................................................................... 10 5.5 Multiple Payment Gateways .......................................................................................... 10 5.6 PCI Compliance............................................................................................................. 10 5.7 Failed Payments............................................................................................................ 11 5.8 Overpayments and Credit Balance................................................................................ 11 5.9 Refunds and Chargebacks ............................................................................................ 11

6 ACCOUNT MANAGEMENT ........................................................................................... 11 6.1 Overview........................................................................................................................ 11



6.2 Customer Account Creation .......................................................................................... 11 6.3 Free Trial Accounts ....................................................................................................... 11 6.4 Customer Account Maintenance ................................................................................... 12 6.5 Updating Credit Cards ................................................................................................... 12 6.6 Cancelling Accounts ...................................................................................................... 12

7 SUBSCRIPTION MANAGEMENT .................................................................................. 13 7.1 Overview........................................................................................................................ 13 7.2 Creating a Subscription ................................................................................................. 13 7.3 Creating Multiple Subscriptions ..................................................................................... 13 7.4 Adding Products to Subscriptions.................................................................................. 13 7.5 Removing Products from Subscriptions ........................................................................ 13 7.6 Updating Products in Subscriptions............................................................................... 13 7.7 Changing Subscription Terms and Conditions .............................................................. 14 7.8 Suspending Subscriptions ............................................................................................. 14 7.9 Cancelling Subscriptions ............................................................................................... 14

8 WEB SELF-SERVICE ..................................................................................................... 14 8.1 Overview........................................................................................................................ 14 8.2 Account Creation and Initial Purchase .......................................................................... 14 8.3 Viewing Information ....................................................................................................... 14 8.4 Updating Information ..................................................................................................... 15

9 ADVANCED COMMERCE MODELS ............................................................................. 15 9.1 Overview........................................................................................................................ 15 9.2 Billing-as-a-Service........................................................................................................ 15 9.3 Cloud Marketplaces....................................................................................................... 16 9.4 Private Clouds ............................................................................................................... 16

10 REPORTING AND METRICS ......................................................................................... 16

11 ACCOUNTING SYSTEM INTEGRATION....................................................................... 17 11.1 Integration Options..................................................................................................... 17 11.2 Accounting Close Process ......................................................................................... 17 11.3 Revenue Recognition................................................................................................. 17

12 OTHER FUNCTIONALITY .............................................................................................. 17 12.1 Taxation ..................................................................................................................... 17 12.2 International Requirements ........................................................................................ 18

13 CONCLUSION ................................................................................................................ 18



1 O v e r v i e w

Recognizing the disruption that cloud computing will have on the technology industry, vendors are rapidly shifting their offerings to the cloud. Emulating early movers like Amazon Web Services, Google App Engine, and Microsoft Azure, many vendors are shifting their business offerings to be more elastic, on-demand, and usage-based.

If your business is making a similar shift, then you have likely started to change your technical infrastructure to be able to deliver elastic computing to your customers. At the same time, the shift to cloud computing will require significant changes to your business model. Instead of making one-time, big-bang purchases of perpetual licenses, your customers in the cloud will now demand to see multiple subscription pricing plans online, pick what is best suited to their needs, and pay on a recurring basis and only for what is used. While perhaps seeming simple at first glance, the cloud business model will have considerable implications on your cloud commerce infrastructure.

This blueprint, based on the best practices that Zuora has accumulated while helping numerous vendors launch their cloud businesses, attempts to highlight all the considerations around metering, pricing, and billing that will need to go into your commerce system to support a successful cloud offering.

2 P r i c i n g a n d P a c k a g i n g

2.1 Overview

Pricing and packaging is a key to succeeding in the cloud. By simply taking a look at the diverse approaches being taken by vendors like Amazon and Microsoft, it is clear that having a system to support multiple pricing models with the ability to make changes in real-time will be a competitive advantage for your business. Whether your goals are to better segment customers, improve cash flow, up-sell additional offerings, or prevent abuse, pricing and packaging is an effective strategic enabler. To that end, this section outlines a variety of pricing and packaging approaches that your commerce system should ideally support.

2.2 One-Time Charges

While you may not adopt it as a component in all your offerings, your system should support the ability to charge customers a one-time fee to get started with your service or to monetize other one-time events such as fixed-cost implementation services.

2.3 Recurring Charges

Your system should allow for your offerings to have a recurring component to the pricing model. Your system should provide the flexibility to define different time intervals for the recurring charges, such as weekly, monthly, quarterly, or yearly. Your system should also support additional complexities, such as when the recurring charges are calculated (e.g., 1st of the month vs. anniversary date) and what proration rules apply (e.g., for partial months). In addition, your system needs to support different types of recurring charges. Recurring charges might be fixed—a flat fee that gets charged each month to customers. Recurring



charges might also be variable—a charge calculated by multiplying units purchased (e.g., application users) by a set price. Or, recurring charges might be calculated based upon detailed usage statistics, a model most commonly seen in the cloud, and the subject discussed next.

2.4 Usage-Based Charges

In the cloud, your customers will demand to pay as they go, and only for what they use. As a result, your commerce system must support usage-based pricing, with the flexibility to charge for virtually any type of computing resource. Some commonly seen computing resources in the cloud that need to be measured on a recurring basis and rated on a usage are:

• Per GB stored • Per IP address • Per GB transferred, inbound and outbound • Per CPU instance, by size • Per VPU instance, by size • Per OS instance • Per internet service • And so on…

Again, your system must enable you to rate usage across any of these computing dimensions and likely create product bundles that include multiple types of resources.

2.5 On Demand Pricing

Your commerce system should enable you to offer pricing plans that charge customers for on-demand usage, the most common model in the cloud. Also called “usage in arrears”, this model charges customers for what they use, after they use it (typically on a monthly interval). For customers, this model offers the greatest flexibility, because advanced planning is unnecessary and long-term commitments are typically not required. You will typically charge customers a higher price for the flexibility of on-demand plans, generating more revenue per resource consumed. On the downside, on demand models make it harder for you to anticipate and plan for capacity needs, enable customers to switch to competitors more easily, and leave you bearing the risk of failed customer payments after resources have been consumed.

2.6 Reservation Pricing

As a cloud vendor, you may also choose to offer reservation pricing plans, whereby customers pay an upfront fee to reserve a certain amount of compute capacity. Some specific reservation pricing models that your commerce system should support are:

• Prepayment Plans: Customers prepay a set amount for “use it or lose it” capacity, and then pay overage charges if that capacity is exceeded.

• Instance Reservation: This approach allows customers to reserve a certain number of computing instances for a low one-time payment (e.g., for a 1- or 3-year term) and then pay a significantly discounted usage rate throughout the duration of that term.

Reservation pricing models generally offer a lower price to customers who have predictable, well-planned consumption requirements. Reservation pricing models provide you the benefits



of being able to better predict capacity needs and also receiving upfront payments to improve cash flow. They can also help reduce customer churn, as the upfront payments lock customers into specified terms. A downside is that the total revenue to you is typically less under a reservation pricing model than it would be on demand.

2.7 Location-Based Pricing

If you have multiple datacenters, you may decide to offer customers the ability to choose which location to house certain workloads (e.g., to reduce the risk of failure). Since the costs to run your datacenters may be different by location, you may then choose to charge different usage-based prices by location. In this case, your commerce system should provide you the flexibility to vary price by location.

2.8 Off-Peak Pricing

During times when your computing capacity is typically underutilized, you may choose to offer customers a lower usage rate. In this case, your commerce system should support the ability to create off-peak pricing plans and then calculate charges differently for peak vs. off-peak consumption.

2.9 Free Trials

Particularly in SaaS (software-as-a-service) cloud businesses, you may offer customers a free trial to evaluate your service prior to converting to a paying account. If free trials are likely to help convert prospects to customers, your commerce system will need to accommodate them. Some configurations that your commerce system should support are:

• Whether a credit card or other method of payment must be provided before the free trial can begin

• Customization of the free trial duration • Reminder notifications as the free trial is about to expire.

2.10 Promotions

To help convert prospects to customers, you may also choose to offer marketing promotions, which can be time-based (e.g., 50% discount for the first 3 months), volume-based (e.g., tiered pricing, whereby additional units become progressively cheaper), or both. Eligibility for promotions can be dictated by a multitude of factors such as geographic location, customer type, etc. The lure of promotions to increase customer acquisition rates is powerful. The downside is that an over-reliance on promotions can erode value and train prospects to demand a promotion before signing up.

2.11 Packaging and Bundling

A quick glance at Amazon reveals that EC2 provides over 216 instance types that a customer can purchase. While your cloud business may not go quite as far as EC2, prospective customers will expect to see you offering a variety of products and pricing plans, so they can feel comfortable choosing one that best suits their needs.



With a multitude of pricing approaches at your fingertips, an important consideration will be the number and types of product packages to offer. Your commerce system must allow you to support numerous product configurations, rapidly experiment when new plans cross your mind, and change dynamically as market or competitive situations dictate it.

3 U s a g e P r o c e s s i n g

3.1 Overview

With your usage-based pricing models, your commerce system will need to be able to meter actual usage as it occurs to track what has been consumed and by whom. Again, usage in the cloud can be measured on nearly every type of computing resource, such as GB stored, GB transferred, CPU instances, API calls made, application users, and much more. This section outlines some of the key requirements around usage processing for your cloud commerce system.

3.2 Metering

Your business must be able to track what has been consumed and by whom. Typically, this information can be obtained from the monitoring software of your underlying infrastructure, but you will need to structure usage records in a consistent manner for your commerce system. Each usage record should minimally have the following:

• Date and Time: when did this usage occur? • Unique Customer ID: Who consumed the service? • Unit of Measure: What was consumed? • Amount: How much was used?

Your commerce system must own the aggregation of all usage data across your multiple infrastructure systems, as well as the billing of customers against that data. In that way, your infrastructure stack need only measure and record the above usage data, rather than being burdened with additional commerce complexity as well.

3.3 Usage Collection and Integration

Your commerce system will need to integrate with your infrastructure layer to pull the underlying usage data. While you can try to tackle this integration manually, the process of generating flat files and uploading data by hand will quickly become too cumbersome and error-prone. Your commerce system will need to support automated data collection from the infrastructure at frequent, pre-specified intervals.

Moreover, the data integration may need to happen from your commerce system to more than one component in your infrastructure stack. For example, your virtualization software may provide a bulk of the usage statistics you need for billing, but you may still need to directly integrate with specific applications for usage or with hardware devices for storage consumption. Ideally, your commerce engine should come with pre-built API-level integration with leading software and hardware infrastructure providers, and/or with middleware integration solutions.



3.4 Rating

Rating refers to the process of translating metering data into invoice items for a customer, based upon her chosen pricing plan. Your system will need to provide a rating engine that can calculate these charges based upon usage data over time. In some instances, you may need your system to be configurable as to how the rating calculations are performed. For example, if you charge $0.15 per gigabyte stored per month, you will need to be able to tell your system how to average storage data across that month (e.g., measure storage every 12 hours and average those data points).

Your choice of the time interval on which to perform rating can also be important, especially with reservation pricing models. For example, choosing a quarterly time interval instead of monthly might be attractive to customers with peak or seasonal demand, since they can average out their spikes in usage across the quarter, rather than needing to reserve for peak demand even in months with a lull. Additional variations such as rollover rating (similar to what is seen in some cell phone plans) can also entice customers, as the downside of “use it or lose it” pricing is minimized. Your system should support these variations in rating approaches.

4 B i l l i n g

4.1 Overview

Billing is the process of creating an invoice that charges customers on a recurring basis according to the pricing plan they have selected, their usage during that time period, and any discounts that may apply. This section outlines the key requirements for a cloud-based billing system.

4.2 Creating Invoices

Your commerce system will need to generate invoices for customers, indicating the payment that is due. In the usage-based world of cloud computing, your customers will demand invoices to be itemized to show one-time charges, recurring charges, and line-by-line usage-based charges.

In some situations, you may decide not to present an invoice to certain customers, particularly ones that are billed automatically each month via credit card. Even for such customers, it is important to create an invoice for your records, for presentment to customers if requested, and for legal requirements in some countries.

4.3 Adjustments

Your system should permit you to make adjustments to invoices. There are two types of adjustments that you will typically make:

• Invoice-level adjustments: allow you to credit (e.g., for customer service reasons) or debit (e.g., for added late fees) an invoice after it has been created.

• Line item-level adjustments: allow you to credit or debit against a specific line item charge on an invoice (e.g., to reverse out a charge that was not really incurred).



4.4 Scheduled Bill Runs

Your system will need to support scheduled bill runs to generate invoices and deliver them to customers. Through this process that can run daily, weekly, monthly, or on another pre-determined time interval, your business can automate the process of identifying the charges to be applied and informing customers about them. One of the greatest risks of a subscription-based cloud business is revenue leakage. For instance, a customer could have an annual service charge that gets applied on his anniversary date. Making sure the annual charge is billed is often problematic when processes are manual. In contrast, scheduled bill runs that incorporate all possible charges will make sure nothing slips through the cracks.

4.5 Ad-Hoc Bill Runs

Your cloud business system will also likely need the flexibility to support ad-hoc bill runs. For example, you might want to generate an ad-hoc invoice for a certain customer earlier than usual, perhaps in a situation where his overdue balance is significant and you want to collect payment early to improve cash flow.

4.6 Billing Approvals

At your discretion, your system should allow you to review and approve the result of bill runs prior to sending invoices to customers and charging them. This capability enables you to spot check invoices and correct mistakes (e.g., where usage data is loaded incorrectly) before sending them to your customers.

4.7 Batching

Your system should support the grouping of customers into batches, where each batch can get run through billing independently from the other batches. For example, you might want to separate credit card customers from larger enterprise customers that pay by check. Other logical groupings to consider are batching by geography (e.g., Americas, EMEA, Asia-Pac) or by taxable vs. non-taxable customers.

4.8 Multi-Channel Delivery

Once you approve, or “post”, the results of a bill run, your system will need to deliver invoices to customers. Your system should be able to deliver invoices to customers by e-mail, traditional mail, or on a web self-service portal.

5 P a y m e n t s

5.1 Overview

This section outlines the key items your commerce system will need to accommodate in order to process payments for your cloud-based services.



5.1 Multiple Payment Types

Your customers will likely request to pay in different ways, so it is important that your commerce system support the key payment types:

• Electronic: These payments are typically electronic bank transfers (e.g., ACH) or credit card transactions that are made with a direct connection between your billing system and the electronic payment processor.

• External: These payments, such as paper checks or wire transfers, are processed outside of your commerce engine and must be recorded against an invoice back in the billing system.

5.2 Ad-Hoc Payments

In all likelihood, most of your customers will pay you against an invoiced amount on a regular basis. However, your system should still support the processing of ad-hoc payments that customers may make. For example, if a customer did not pay you the full invoice amount in a previous statement period, you may need to process an ad-hoc payment to cover the outstanding balance.

5.3 Scheduled Payment Runs

For customers that pay electronically, your system should accommodate the scheduling of automated payment runs that charge their accounts or credit cards at a regular, recurring time interval.

5.4 Payment Gateway Integration

In order to accept credit cards and electronic checks, you will need a relationship with a payment gateway (e.g., PayPal, Authorize.net, CyberSource) to authorize transactions. Your commerce system must be able to integrate with the payment gateway you have selected in order to automatically charge the credit cards of your customers on a recurring basis.

5.5 Multiple Payment Gateways

As your business grows, your payment gateway needs may evolve. For instance, if you decide to expand into Denmark, your payment gateway may not be able to support credit card processing for that country. Having a commerce system that supports connections to multiple gateways is essential to ensure that your growth is not hindered by an inability to accept payments.

Your commerce system should also allow you to change gateways seamlessly, so your end customers do not need to re-enter their credit card information when you add or change a gateway contract.

5.6 PCI Compliance

If you intend to process credit cards as a method of payment, best practices will dictate that your commerce system be PCI compliant, thereby achieving a level of security that meets the



standards of the Payment Card Industry (PCI) and giving your customers comfort that their credit card information is protected.

5.7 Failed Payments

When you schedule automated payment runs, your system should allow you to define how many times you want to retry failed transactions on a specific credit card. For example, you may define up to three additional attempts, and designate that a specific amount of time (e.g., 12 or 24 hours) must pass between retry attempts. In addition, your system should provide you and your customer with automated notifications should all retry attempts ultimately fail.

5.8 Overpayments and Credit Balance

Customers will sometimes overpay the amount due, for example, by rounding up a check or erroneously paying more than the current invoice amount. In these situations, your commerce system should ideally allow you to accept these overpayments and hold them as credits for the customer that can be automatically applied against future usage of your service. With support for credit balances, your business can avoid many time consuming refund processes.

5.9 Refunds and Chargebacks

Your cloud commerce system must support customer refunds when requested for overpayments or perhaps for unmet service level agreements. In addition, your system should be able to support chargebacks, which are funds needing to be returned to customers for contested charges. Customers typically request chargebacks for fraudulent purchases made on their credit cards, clerical errors (e.g., duplicate billing), or services purchased but never received.

6 A c c o u n t M a n a g e m e n t

6.1 Overview

This section discusses key system requirements regarding the creation and maintenance of customer accounts.

6.2 Customer Account Creation

When creating a new customer account, your system should only collect information you absolutely need, to keep the process short and minimize customer abandonment. Information typically required will be: name, password, key contact and billing information, and payment information.

6.3 Free Trial Accounts

If your business offers a free trial period, you will need to decide whether your system will collect credit card information prior to starting the free trial. Prior collection of credit card information will likely lower your free trial customer acquisition rate but increase your conversion rate from free to paying customers downstream. Testing both approaches is a good way to measure which approach works best for your business, and so your system should accommodate such experimentation.



6.4 Customer Account Maintenance

Your system should allow your service agents and customers to access a customer account and modify its details. In addition to the information entered during account creation, your system should also likely allow for the editing of the following customer account details:

• Locale: information about the customer’s time zone and date format preferences • Currency: the currency that is used to charge the customer • Tax Exemption: a customer’s tax exemption status (typically not editable directly by a

customer) • Payment Terms: you may want flexibility to offer both net 15 or net 30 terms (typically

not editable directly by a customer) • Payment Methods: your system should ideally support entry of multiple payment

methods, in addition to selection of one default payment method • Additional Contacts: for example, you may want to store different “bill to” and “sold to”

contacts for a particular customer.

6.5 Updating Credit Cards

A key difference between a widget-based shopping cart and a cloud commerce system is the recurring nature of customer charges. Once a credit card is on file for cloud recurring charges, there is the possibility that the credit card will expire or the cardholder will cancel her credit card. Your system should be proactive about notifying customers via e-mail and alerts on your web portal when their credit cards are about to expire. This proactive, automated approach will reduce the number of failed payments and ultimately improve your cash flow. Your system can ideally also leverage value-added services from Visa and MasterCard, allowing you to automatically update credit card numbers and expiration dates, so you will always have a customer’s latest credit card information.

6.6 Cancelling Accounts

Your system will need to support cancellation of customer accounts. Customers should be able to cancel accounts in a self-service manner, and your support representatives should also be able to cancel accounts, either at a customer's request or for other business reasons such as non-payment or fraudulent use. Delving deeper, here are additional things your system must support during account cancellation, largely to minimize the risk of revenue leakage:

• Before canceling an account, your system should cancel all of the customer's subscriptions and verify that all due invoices have been paid or adjusted.

• The system should prohibit further subscriptions from being added to a canceled account.

• The system must ensure that any remaining usage prior to account cancellation gets billed to the customer in the next billing cycle.

• Optionally, you may consider having your system cancel all of a customer’s subscriptions but keep the customer account active, so the customer can reengage without friction at a later date, with her existing account information still intact.



7 S u b s c r i p t i o n M a n a g e m e n t

7.1 Overview

When a customer purchases one of your cloud offerings, your system will need to create a subscription for that customer, defining what has been purchased, by whom, over what time horizon, and at what pricing rate. This section outlines the various requirements your commerce system will need to support both in creating subscriptions and in managing changes against it throughout a customer’s lifecycle with you.

7.2 Creating a Subscription

Your commerce system should create a subscription when a customer makes a purchase from you. Some key information that should be captured in a subscription includes:

• Customer Name and ID: identifying the customer who made the purchase • Initial Term: the duration for the subscription • Start Date: the date that the subscription begins • Auto Renew: whether the subscription should automatically renew at the end of the term • Renewal Term: the duration for a subscription renewal • Products Purchased: the products that comprise the subscription • Product Pricing: the amount to be charged for each product purchased, which can

include one-time fees, recurring fees, and usage-based fees • Billing Interval: the interval (e.g., monthly, quarterly, etc.) over which recurring charges

are billed.

7.3 Creating Multiple Subscriptions

As your business grows, you may want to offer an additional product line to your existing customers. It is important that your commerce system allows you to create multiple subscriptions for an account so you can, for example, allow your customers to try out the new offering without impacting their existing service.

7.4 Adding Products to Subscriptions

In the event that you upsell more products or services to a customer later, your system should support the addition of those items to an existing customer subscription.

7.5 Removing Products from Subscriptions

If a customer decides to downgrade from what he originally purchased (e.g., remove a promotional product after its “teaser rate” has expired), your system should support the removal of specific products from that customer’s subscription.

7.6 Updating Products in Subscriptions

Your system should allow you to make changes to a product within a subscription if you wish to alter the price charged to the customer for that product. For example, you might want to increase the cost of your physical data backup service over time, to reflect changes in the price of postage to deliver those backups.



7.7 Changing Subscription Terms and Conditions

In some cases, your system may need to support the ability to change the terms and conditions outlined in a customer’s original contract. For example, rather than issuing a refund to a customer, you may both agree to simply provide that customer with a credit extending the length of her contract by three months.

7.8 Suspending Subscriptions

Your commerce system may need to permit a customer to suspend his subscription to your service for a certain period of time. Similar to how you would personally suspend your home newspaper subscription when going on vacation, a cloud customer might choose to suspend his subscription to your high-CPU instances in the summer months when business is slow.

7.9 Cancelling Subscriptions

Your system must allow customers to cancel subscriptions to services that are no longer needed. For example, a customer may cancel her trial subscription at the end of the free promotional period, without converting into a paying customer. Since a customer can have more than one subscription, your system must allow a customer to cancel one subscription while keeping others active.

8 W e b S e l f - S e r v i c e

8.1 Overview

In the cloud, many of your customers will no longer be making large one-time purchases from your direct sales force. Instead, they may prefer to purchase on demand, only for what is used, and self-service from your website. Your commerce system will need to provide functionality for customers to create and manage their accounts on the web and in a self-service manner.

8.2 Account Creation and Initial Purchase

Your web storefront should allow a new customer to create an account and make an initial purchase online.

8.3 Viewing Information

Returning customers should be provided with a login and password to access your web self-service portal. From the web, a customer should be able to view the following information:

• Account Profile: typically a customer’s contact and billing information • Payment Method: the payment method used for any recurring billing. For credit card

details, only the last four digits and the expiration date should be displayed for security purposes.

• Subscription Details: information related to the products and services that a customer has purchased from you, along with their corresponding rate plans

• Invoices: a record of the invoices you’ve generated for that customer • Payments and Adjustments: the history of payments that a customer has made and any

billing adjustments you have made for the account



• Current Usage and Charges: a snapshot of the customer’s consumption of your cloud services for the current billing period, as well as a calculation of how his upcoming bill current stands.

8.4 Updating Information

Your system should also allow customers to make changes to their accounts from your web self-service portal, thereby saving you from significant customer support costs. Common self-service updates that your system should support are:

• Changing account user name and password • Changing contact information for that account • Updating the payment information for an account (e.g., adding a different credit card or

changing a card’s expiration date) • Adding, removing, or updating products in a subscription • Creating, suspending, or cancelling a subscription.

9 A d v a n c e d C o m m e r c e M o d e l s

9.1 Overview

This section briefly highlights some advanced commerce models in the cloud and considerations that must be made for each of those models.

9.2 Billing-as-a-Service

As a cloud provider, you will likely have ISVs (independent software vendors) building solutions on your infrastructure, and you may also have resellers wanting to “white label” your offering. In this case, these ISVs and resellers will need a commerce system to meter, price, and bill their own customers. If designed properly, your billing system can be offered as a service to these ISVs and resellers. In addition to everything already discussed in this document, here are a few additional requirements to consider for such an offering:

• Pass-Through of Usage Charges: As part of its pricing plan, an ISV or reseller may simply want to pass usage charges for your cloud offering to its specific customers that consume those resources. Your billing-as-a-service system must be equipped to handle this multi-tier metering and allocation (i.e., metering and allocation of your customer’s customers).

• Configurable Pricing: An ISV may want to price differently than you do. For example, many ISVs will want to charge per application user, whereas you charge for compute resources consumed. Your billing-as-a-service system must support this level of customization.

• Personalization: ISVs and resellers that use your billing-as-a-service offering will want to attach their branding, not yours, to any interactions with their customers. For example, when generating invoices on behalf of an ISV using your cloud, your system should allow those invoices to display the ISV’s logo and contact information, not yours. The same holds for any e-mails or notifications that get sent to the ISV’s customers.

• Security: Before offering billing-as-a-service, you must be sure that your system properly supports multi-tenancy and/or other security safeguards to eliminate risk that one



customer’s financial information gets inappropriately seen by another customer. • Billing for Your Service: Obviously, your own commerce engine will need to support this

billing-as-a-service offering as a new shopping cart item that your customers can purchase and be billed for on a recurring basis.

9.3 Cloud Marketplaces

As a cloud provider, you may be in a position to connect together an ecosystem of buyers and sellers of subscription-based cloud services in an “App Store”-like marketplace. For example, in addition to compute resources that you directly provide, sellers in your ecosystem might offer additional software applications or services, for which you would share in the revenue. In such a marketplace, your commerce engine would need to support:

• Revenue Sharing: Your system must accurately bill customers on a recurring basis for applications and services they purchase from sellers in your ecosystem. Then, it must automatically allocate those proceeds according to a pre-determined revenue sharing formula that might differ from seller to seller.

• Configurable Pricing: Your system must give sellers in your ecosystem the capability to define pricing for their offerings in your marketplace, perhaps within some constraints that you place on the marketplace as a whole (e.g., you might choose only to support one-time and monthly pricing models).

• Shopping a la Carte: Your online storefront will need to display these marketplace offerings in an intuitive and engaging way to shoppers, perhaps even promoting certain “hot sellers”. Buyers should be able to purchase self-service from these “a la carte” offerings and return at a later date to add or remove items from the marketplace.

9.4 Private Clouds

If you are an IT executive setting up a private cloud within your enterprise or a hosting provider setting up a private cloud on behalf of an enterprise, some of the commerce considerations in this document will not apply. That said, you will still likely need a system that can measure usage by cost center (e.g., by department, branch office, etc.) and rate that usage according to some monetary equation, potentially using local currencies from where the usage occurs. Then, on a recurring basis, you will need to chargeback the various departments in your organization for usage of your private cloud. Even if your internal accounting practices are not so formal as to require a chargeback model, a common practice these days is to present “showback” reports to senior management for full visibility into what resources are being consumed and by whom.

1 0 R e p o r t i n g a n d M e t r i c s

Your cloud business will operate differently from manufacturing, order-based businesses. As such, your system should provide you with ready access to reports and metrics appropriate for the cloud. Some important metrics to consider include:

• Total Customer Value (TCV) • Monthly Recurring Revenue (MRR) • Cash Flow • Churn • Customer Lifetime Value.



If your system provides you with the ability to generate reports that display these and other subscription-oriented metrics, your business will be equipped to make the best business decisions in the cloud.

1 1 A c c o u n t i n g S y s t e m I n t e g r a t i o n

11.1 Integration Options

Your commerce system will need to integrate with an accounting system to create your company’s financial statements. There are two common approaches to integrating billing data:

• GL Integration: The benefit of this approach is to unburden the accounting system. Customer accounts, usage, invoices, and A/R are managed in the commerce system, and a summarization of this data by GL accounting code is loaded into the accounting system as journal entries.

• Invoice Integration: This approach passes customer information, invoice line details, payments, and adjustments to the accounting system. The accounting system then aggregates the information into the General Ledger.

11.2 Accounting Close Process

Regardless of the accounting integration approach, your commerce system should have the ability to lock down the data therein as part of an accounting close process. Your commerce system should allow for extensive flexibility to create invoices, payments, and other financial transactions during the month. When the accounting books are closed, however, there should be no ability to change transactions or create new ones in the closed period.

11.3 Revenue Recognition

The driving force behind revenue recognition is that you can only earn revenue as the service is delivered. With arrears-based usage models where you invoice after the service is used, revenue recognition is not a challenge. However, if your pricing model includes cycle-forward billing where you bill ahead for a specified period of time (e.g., a quarter or a year), you will need to need to recognize this revenue as it is earned. Your commerce system should have the ability to invoice charges and trigger revenue recognition at a different time. For instance, you may want to invoice a one-time setup fee as soon as the contract is signed, but not start revenue recognition until the service is activated. Another common complication for cloud businesses is in recognizing a one-time charge over the length of a contract, or even the average customer lifetime. The commerce system will need to be able to invoice for these one-time charges, but enable revenue to be recognized over these longer service periods.

1 2 O t h e r F u n c t i o n a l i t y

12.1 Taxation

As a cloud provider, you will likely need to apply taxes. Over the past several years, taxation rules have rapidly evolved, and with state and local tax authorities looking for sources of new



revenue, taxation for cloud businesses will quickly become a requirement. Each charge in your bundle of pricing may have different tax rules. For instance, some states charge taxes on professional services but not on internet access, so your commerce system will need the ability to apply taxes differently for each type of product that you offer. European Union Value Added Tax and Canadian Provincial and Federal Taxes also present challenges to cloud providers. A commerce system that has the ability to support global taxation will fuel your ability to offer services to international customers. Some of your customers, such as charities or churches, will be exempt from taxes. These customers will need to provide proof of their tax exemption, and your commerce system will need the ability to not apply taxes on a customer-by-customer basis. There are three concepts that drive taxation calculations:

• Nexus: Depending on where your company has a physical presence, you will be responsible for taxes associated to that nexus or location.

• Product: Tax codes are associated with the products you sell. Each product may have different tax treatments. For instance, bandwidth usage may be classified as internet access in some states and internet service in others.

• Tax Rates: Tax rates are the values that will be used for the calculation of taxes, in conjunction with the sold to address, your nexus, and the classification of the product.

12.2 International Requirements

Since “the cloud” implies that your service can be used from anywhere, you will need to decide whether international customers can sign-up for your service. If so, you will need a system that supports multiple currency types and date formats. In addition, you may also need a system (and particularly a web self-service portal) that can be localized in the languages of the countries where you primarily do business.

1 3 C o n c l u s i o n “With Sun Cloud, we were early movers to cloud computing. But without the right systems to meter,

price, and bill in the cloud, we couldn’t bring our offering to market.” -Lew Tucker, former CTO of Cloud Computing, Sun Microsystems

We hope that this Zuora blueprint has provided you with a good sense of all the business model considerations you will need to make before launching your cloud offering. Of course, not all of the items outlined in this document may be applicable for your business, but chances are that many of them will be. If you feel intimidated by all the work that remains in front of you, then you are not alone. Most of the leading vendors that Zuora has helped launch into the cloud have faced similar challenges. By reading this blueprint, you at least have an early start in thinking through your cloud business model from end-to-end, reducing the likelihood that when your cloud technology offering is ready, your commerce system will still have lots of catching up to do. If you realize that your existing commerce system cannot handle the cloud business model, then



you are also not alone. Most of Zuora’s cloud customers reached out to us when they hit the wall with their traditional ERP or legacy systems and realized that a further customization effort would be too costly and daunting. In any event, we invite you to contact Zuora to learn more. As the leader in subscription billing and cloud commerce, we are interested to hear about your business and discuss how a partnership with Zuora might accelerate your path to the cloud.

z commerce-for-the-cloud-blueprint

Economy & Finance

improve cash flow

hoc bill runs

commerce system willneed

cloud business model

credit card

credit cards

key requirements

commerce engine