• Like
  • Save
Z commerce-for-the-cloud-blueprint
Upcoming SlideShare
Loading in...5
×
 

Z commerce-for-the-cloud-blueprint

on

  • 822 views

 

Statistics

Views

Total Views
822
Views on SlideShare
822
Embed Views
0

Actions

Likes
0
Downloads
38
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Z commerce-for-the-cloud-blueprint Z commerce-for-the-cloud-blueprint Document Transcript

    • Blueprint for the CloudA guide to metering, pricing, and billing for cloud commerceJune 2010© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited.
    • Zuora Blueprint for the CloudTable of Contents1   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  © 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 2 of 19
    • Zuora Blueprint for the Cloud 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  © 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 3 of 19
    • Zuora Blueprint for the Cloud1 OverviewRecognizing the disruption that cloud computing will have on the technology industry, vendorsare rapidly shifting their offerings to the cloud. Emulating early movers like Amazon WebServices, Google App Engine, and Microsoft Azure, many vendors are shifting their businessofferings 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 technicalinfrastructure to be able to deliver elastic computing to your customers. At the same time, theshift to cloud computing will require significant changes to your business model. Instead ofmaking one-time, big-bang purchases of perpetual licenses, your customers in the cloud willnow demand to see multiple subscription pricing plans online, pick what is best suited to theirneeds, and pay on a recurring basis and only for what is used. While perhaps seeming simpleat first glance, the cloud business model will have considerable implications on your cloudcommerce infrastructure.This blueprint, based on the best practices that Zuora has accumulated while helping numerousvendors launch their cloud businesses, attempts to highlight all the considerations aroundmetering, pricing, and billing that will need to go into your commerce system to support asuccessful cloud offering.2 Pricing and Packaging2.1 OverviewPricing and packaging is a key to succeeding in the cloud. By simply taking a look at thediverse approaches being taken by vendors like Amazon and Microsoft, it is clear that having asystem to support multiple pricing models with the ability to make changes in real-time will be acompetitive 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 aneffective strategic enabler. To that end, this section outlines a variety of pricing and packagingapproaches that your commerce system should ideally support.2.2 One-Time ChargesWhile you may not adopt it as a component in all your offerings, your system should support theability to charge customers a one-time fee to get started with your service or to monetize otherone-time events such as fixed-cost implementation services.2.3 Recurring ChargesYour 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 recurringcharges, such as weekly, monthly, quarterly, or yearly. Your system should also supportadditional complexities, such as when the recurring charges are calculated (e.g., 1st of themonth 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. Recurringcharges might be fixed—a flat fee that gets charged each month to customers. Recurring© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 4 of 19
    • Zuora Blueprint for the Cloudcharges 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 detailedusage statistics, a model most commonly seen in the cloud, and the subject discussed next.2.4 Usage-Based ChargesIn the cloud, your customers will demand to pay as they go, and only for what they use. As aresult, your commerce system must support usage-based pricing, with the flexibility to chargefor virtually any type of computing resource. Some commonly seen computing resources in thecloud 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 dimensionsand likely create product bundles that include multiple types of resources.2.5 On Demand PricingYour 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 modelcharges customers for what they use, after they use it (typically on a monthly interval). Forcustomers, this model offers the greatest flexibility, because advanced planning is unnecessaryand 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 makeit harder for you to anticipate and plan for capacity needs, enable customers to switch tocompetitors more easily, and leave you bearing the risk of failed customer payments afterresources have been consumed.2.6 Reservation PricingAs a cloud vendor, you may also choose to offer reservation pricing plans, whereby customerspay an upfront fee to reserve a certain amount of compute capacity. Some specific reservationpricing 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© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 5 of 19
    • Zuora Blueprint for the Cloudof being able to better predict capacity needs and also receiving upfront payments to improvecash flow. They can also help reduce customer churn, as the upfront payments lock customersinto specified terms. A downside is that the total revenue to you is typically less under areservation pricing model than it would be on demand.2.7 Location-Based PricingIf you have multiple datacenters, you may decide to offer customers the ability to choose whichlocation to house certain workloads (e.g., to reduce the risk of failure). Since the costs to runyour 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 flexibilityto vary price by location.2.8 Off-Peak PricingDuring times when your computing capacity is typically underutilized, you may choose to offercustomers a lower usage rate. In this case, your commerce system should support the ability tocreate off-peak pricing plans and then calculate charges differently for peak vs. off-peakconsumption.2.9 Free TrialsParticularly in SaaS (software-as-a-service) cloud businesses, you may offer customers a freetrial to evaluate your service prior to converting to a paying account. If free trials are likely tohelp 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 PromotionsTo 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., tieredpricing, whereby additional units become progressively cheaper), or both. Eligibility forpromotions can be dictated by a multitude of factors such as geographic location, customertype, etc.The lure of promotions to increase customer acquisition rates is powerful. The downside is thatan over-reliance on promotions can erode value and train prospects to demand a promotionbefore signing up.2.11 Packaging and BundlingA quick glance at Amazon reveals that EC2 provides over 216 instance types that a customercan purchase. While your cloud business may not go quite as far as EC2, prospectivecustomers will expect to see you offering a variety of products and pricing plans, so they canfeel comfortable choosing one that best suits their needs.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 6 of 19
    • Zuora Blueprint for the CloudWith a multitude of pricing approaches at your fingertips, an important consideration will be thenumber and types of product packages to offer. Your commerce system must allow you tosupport numerous product configurations, rapidly experiment when new plans cross your mind,and change dynamically as market or competitive situations dictate it.3 Usage Processing3.1 OverviewWith your usage-based pricing models, your commerce system will need to be able to meteractual usage as it occurs to track what has been consumed and by whom. Again, usage in thecloud can be measured on nearly every type of computing resource, such as GB stored, GBtransferred, CPU instances, API calls made, application users, and much more. This sectionoutlines some of the key requirements around usage processing for your cloud commercesystem.3.2 MeteringYour business must be able to track what has been consumed and by whom. Typically, thisinformation can be obtained from the monitoring software of your underlying infrastructure, butyou 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 multipleinfrastructure systems, as well as the billing of customers against that data. In that way, yourinfrastructure stack need only measure and record the above usage data, rather than beingburdened with additional commerce complexity as well.3.3 Usage Collection and IntegrationYour commerce system will need to integrate with your infrastructure layer to pull the underlyingusage data. While you can try to tackle this integration manually, the process of generating flatfiles and uploading data by hand will quickly become too cumbersome and error-prone. Yourcommerce system will need to support automated data collection from the infrastructure atfrequent, pre-specified intervals.Moreover, the data integration may need to happen from your commerce system to more thanone component in your infrastructure stack. For example, your virtualization software mayprovide a bulk of the usage statistics you need for billing, but you may still need to directlyintegrate 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 leadingsoftware and hardware infrastructure providers, and/or with middleware integration solutions.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 7 of 19
    • Zuora Blueprint for the Cloud3.4 RatingRating 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 cancalculate these charges based upon usage data over time. In some instances, you may needyour system to be configurable as to how the rating calculations are performed. For example, ifyou charge $0.15 per gigabyte stored per month, you will need to be able to tell your systemhow to average storage data across that month (e.g., measure storage every 12 hours andaverage those data points).Your choice of the time interval on which to perform rating can also be important, especially withreservation pricing models. For example, choosing a quarterly time interval instead of monthlymight be attractive to customers with peak or seasonal demand, since they can average outtheir spikes in usage across the quarter, rather than needing to reserve for peak demand evenin months with a lull. Additional variations such as rollover rating (similar to what is seen insome cell phone plans) can also entice customers, as the downside of “use it or lose it” pricingis minimized. Your system should support these variations in rating approaches.4 Billing4.1 OverviewBilling is the process of creating an invoice that charges customers on a recurring basisaccording to the pricing plan they have selected, their usage during that time period, and anydiscounts that may apply. This section outlines the key requirements for a cloud-based billingsystem.4.2 Creating InvoicesYour commerce system will need to generate invoices for customers, indicating the paymentthat is due. In the usage-based world of cloud computing, your customers will demand invoicesto be itemized to show one-time charges, recurring charges, and line-by-line usage-basedcharges.In some situations, you may decide not to present an invoice to certain customers, particularlyones that are billed automatically each month via credit card. Even for such customers, it isimportant to create an invoice for your records, for presentment to customers if requested, andfor legal requirements in some countries.4.3 AdjustmentsYour system should permit you to make adjustments to invoices. There are two types ofadjustments 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).© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 8 of 19
    • Zuora Blueprint for the Cloud4.4 Scheduled Bill RunsYour system will need to support scheduled bill runs to generate invoices and deliver them tocustomers. 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 tobe applied and informing customers about them.One of the greatest risks of a subscription-based cloud business is revenue leakage. Forinstance, a customer could have an annual service charge that gets applied on his anniversarydate. 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 slipsthrough the cracks.4.5 Ad-Hoc Bill RunsYour cloud business system will also likely need the flexibility to support ad-hoc bill runs. Forexample, you might want to generate an ad-hoc invoice for a certain customer earlier thanusual, perhaps in a situation where his overdue balance is significant and you want to collectpayment early to improve cash flow.4.6 Billing ApprovalsAt your discretion, your system should allow you to review and approve the result of bill runsprior to sending invoices to customers and charging them. This capability enables you to spotcheck invoices and correct mistakes (e.g., where usage data is loaded incorrectly) beforesending them to your customers.4.7 BatchingYour system should support the grouping of customers into batches, where each batch can getrun through billing independently from the other batches. For example, you might want toseparate credit card customers from larger enterprise customers that pay by check. Otherlogical groupings to consider are batching by geography (e.g., Americas, EMEA, Asia-Pac) orby taxable vs. non-taxable customers.4.8 Multi-Channel DeliveryOnce you approve, or “post”, the results of a bill run, your system will need to deliver invoices tocustomers. Your system should be able to deliver invoices to customers by e-mail, traditionalmail, or on a web self-service portal.5 Payments5.1 OverviewThis section outlines the key items your commerce system will need to accommodate in order toprocess payments for your cloud-based services.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 9 of 19
    • Zuora Blueprint for the Cloud5.1 Multiple Payment TypesYour customers will likely request to pay in different ways, so it is important that your commercesystem 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 PaymentsIn all likelihood, most of your customers will pay you against an invoiced amount on a regularbasis. However, your system should still support the processing of ad-hoc payments thatcustomers may make. For example, if a customer did not pay you the full invoice amount in aprevious statement period, you may need to process an ad-hoc payment to cover theoutstanding balance.5.3 Scheduled Payment RunsFor customers that pay electronically, your system should accommodate the scheduling ofautomated payment runs that charge their accounts or credit cards at a regular, recurring timeinterval.5.4 Payment Gateway IntegrationIn order to accept credit cards and electronic checks, you will need a relationship with apayment gateway (e.g., PayPal, Authorize.net, CyberSource) to authorize transactions. Yourcommerce system must be able to integrate with the payment gateway you have selected inorder to automatically charge the credit cards of your customers on a recurring basis.5.5 Multiple Payment GatewaysAs your business grows, your payment gateway needs may evolve. For instance, if you decideto expand into Denmark, your payment gateway may not be able to support credit cardprocessing for that country. Having a commerce system that supports connections to multiplegateways is essential to ensure that your growth is not hindered by an inability to acceptpayments.Your commerce system should also allow you to change gateways seamlessly, so your endcustomers do not need to re-enter their credit card information when you add or change agateway contract.5.6 PCI ComplianceIf you intend to process credit cards as a method of payment, best practices will dictate thatyour commerce system be PCI compliant, thereby achieving a level of security that meets the© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 10 of 19
    • Zuora Blueprint for the Cloudstandards of the Payment Card Industry (PCI) and giving your customers comfort that theircredit card information is protected.5.7 Failed PaymentsWhen you schedule automated payment runs, your system should allow you to define howmany times you want to retry failed transactions on a specific credit card. For example, youmay 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 youand your customer with automated notifications should all retry attempts ultimately fail.5.8 Overpayments and Credit BalanceCustomers will sometimes overpay the amount due, for example, by rounding up a check orerroneously paying more than the current invoice amount. In these situations, your commercesystem should ideally allow you to accept these overpayments and hold them as credits for thecustomer that can be automatically applied against future usage of your service. With supportfor credit balances, your business can avoid many time consuming refund processes.5.9 Refunds and ChargebacksYour cloud commerce system must support customer refunds when requested foroverpayments or perhaps for unmet service level agreements.In addition, your system should be able to support chargebacks, which are funds needing to bereturned to customers for contested charges. Customers typically request chargebacks forfraudulent purchases made on their credit cards, clerical errors (e.g., duplicate billing), orservices purchased but never received.6 Account Management6.1 OverviewThis section discusses key system requirements regarding the creation and maintenance ofcustomer accounts.6.2 Customer Account CreationWhen creating a new customer account, your system should only collect information youabsolutely need, to keep the process short and minimize customer abandonment. Informationtypically required will be: name, password, key contact and billing information, and paymentinformation.6.3 Free Trial AccountsIf your business offers a free trial period, you will need to decide whether your system will collectcredit card information prior to starting the free trial. Prior collection of credit card informationwill likely lower your free trial customer acquisition rate but increase your conversion rate fromfree to paying customers downstream. Testing both approaches is a good way to measurewhich approach works best for your business, and so your system should accommodate suchexperimentation.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 11 of 19
    • Zuora Blueprint for the Cloud6.4 Customer Account MaintenanceYour system should allow your service agents and customers to access a customer accountand modify its details. In addition to the information entered during account creation, yoursystem 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 CardsA key difference between a widget-based shopping cart and a cloud commerce system is therecurring 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 webportal when their credit cards are about to expire. This proactive, automated approach willreduce 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 willalways have a customer’s latest credit card information.6.6 Cancelling AccountsYour system will need to support cancellation of customer accounts. Customers should be ableto cancel accounts in a self-service manner, and your support representatives should also beable to cancel accounts, either at a customers request or for other business reasons such asnon-payment or fraudulent use. Delving deeper, here are additional things your system mustsupport during account cancellation, largely to minimize the risk of revenue leakage: • Before canceling an account, your system should cancel all of the customers 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.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 12 of 19
    • Zuora Blueprint for the Cloud7 Subscription Management7.1 OverviewWhen a customer purchases one of your cloud offerings, your system will need to create asubscription for that customer, defining what has been purchased, by whom, over what timehorizon, and at what pricing rate. This section outlines the various requirements yourcommerce system will need to support both in creating subscriptions and in managing changesagainst it throughout a customer’s lifecycle with you.7.2 Creating a SubscriptionYour commerce system should create a subscription when a customer makes a purchase fromyou. 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 SubscriptionsAs your business grows, you may want to offer an additional product line to your existingcustomers. It is important that your commerce system allows you to create multiplesubscriptions for an account so you can, for example, allow your customers to try out the newoffering without impacting their existing service.7.4 Adding Products to SubscriptionsIn the event that you upsell more products or services to a customer later, your system shouldsupport the addition of those items to an existing customer subscription.7.5 Removing Products from SubscriptionsIf a customer decides to downgrade from what he originally purchased (e.g., remove apromotional product after its “teaser rate” has expired), your system should support the removalof specific products from that customer’s subscription.7.6 Updating Products in SubscriptionsYour system should allow you to make changes to a product within a subscription if you wish toalter the price charged to the customer for that product. For example, you might want toincrease the cost of your physical data backup service over time, to reflect changes in the priceof postage to deliver those backups.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 13 of 19
    • Zuora Blueprint for the Cloud7.7 Changing Subscription Terms and ConditionsIn some cases, your system may need to support the ability to change the terms and conditionsoutlined in a customer’s original contract. For example, rather than issuing a refund to acustomer, you may both agree to simply provide that customer with a credit extending the lengthof her contract by three months.7.8 Suspending SubscriptionsYour commerce system may need to permit a customer to suspend his subscription to yourservice for a certain period of time. Similar to how you would personally suspend your homenewspaper subscription when going on vacation, a cloud customer might choose to suspend hissubscription to your high-CPU instances in the summer months when business is slow.7.9 Cancelling SubscriptionsYour system must allow customers to cancel subscriptions to services that are no longerneeded. For example, a customer may cancel her trial subscription at the end of the freepromotional period, without converting into a paying customer.Since a customer can have more than one subscription, your system must allow a customer tocancel one subscription while keeping others active.8 Web Self-Service8.1 OverviewIn the cloud, many of your customers will no longer be making large one-time purchases fromyour 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 forcustomers to create and manage their accounts on the web and in a self-service manner.8.2 Account Creation and Initial PurchaseYour web storefront should allow a new customer to create an account and make an initialpurchase online.8.3 Viewing InformationReturning 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© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 14 of 19
    • Zuora Blueprint for the Cloud • 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 InformationYour system should also allow customers to make changes to their accounts from your webself-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 Advanced Commerce Models9.1 OverviewThis section briefly highlights some advanced commerce models in the cloud andconsiderations that must be made for each of those models.9.2 Billing-as-a-ServiceAs a cloud provider, you will likely have ISVs (independent software vendors) building solutionson your infrastructure, and you may also have resellers wanting to “white label” your offering. Inthis case, these ISVs and resellers will need a commerce system to meter, price, and bill theirown 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 additionalrequirements 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© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 15 of 19
    • Zuora Blueprint for the Cloud 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 MarketplacesAs a cloud provider, you may be in a position to connect together an ecosystem of buyers andsellers of subscription-based cloud services in an “App Store”-like marketplace. For example, inaddition to compute resources that you directly provide, sellers in your ecosystem might offeradditional software applications or services, for which you would share in the revenue. In sucha 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 CloudsIf you are an IT executive setting up a private cloud within your enterprise or a hosting providersetting up a private cloud on behalf of an enterprise, some of the commerce considerations inthis document will not apply. That said, you will still likely need a system that can measureusage by cost center (e.g., by department, branch office, etc.) and rate that usage according tosome 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 organizationfor usage of your private cloud. Even if your internal accounting practices are not so formal asto require a chargeback model, a common practice these days is to present “showback” reportsto senior management for full visibility into what resources are being consumed and by whom.10 Reporting and MetricsYour cloud business will operate differently from manufacturing, order-based businesses. Assuch, your system should provide you with ready access to reports and metrics appropriate forthe cloud. Some important metrics to consider include: • Total Customer Value (TCV) • Monthly Recurring Revenue (MRR) • Cash Flow • Churn • Customer Lifetime Value.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 16 of 19
    • Zuora Blueprint for the CloudIf your system provides you with the ability to generate reports that display these and othersubscription-oriented metrics, your business will be equipped to make the best businessdecisions in the cloud.11 Accounting System Integration11.1 Integration OptionsYour commerce system will need to integrate with an accounting system to create yourcompany’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 ProcessRegardless of the accounting integration approach, your commerce system should have theability to lock down the data therein as part of an accounting close process. Your commercesystem should allow for extensive flexibility to create invoices, payments, and other financialtransactions during the month. When the accounting books are closed, however, there shouldbe no ability to change transactions or create new ones in the closed period.11.3 Revenue RecognitionThe driving force behind revenue recognition is that you can only earn revenue as the service isdelivered. 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-forwardbilling where you bill ahead for a specified period of time (e.g., a quarter or a year), you willneed to need to recognize this revenue as it is earned.Your commerce system should have the ability to invoice charges and trigger revenuerecognition at a different time. For instance, you may want to invoice a one-time setup fee assoon 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 thelength of a contract, or even the average customer lifetime. The commerce system will need tobe able to invoice for these one-time charges, but enable revenue to be recognized over theselonger service periods.12 Other Functionality12.1 TaxationAs a cloud provider, you will likely need to apply taxes. Over the past several years, taxationrules have rapidly evolved, and with state and local tax authorities looking for sources of new© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 17 of 19
    • Zuora Blueprint for the Cloudrevenue, taxation for cloud businesses will quickly become a requirement.Each charge in your bundle of pricing may have different tax rules. For instance, some statescharge taxes on professional services but not on internet access, so your commerce system willneed 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 presentchallenges to cloud providers. A commerce system that has the ability to support globaltaxation will fuel your ability to offer services to international customers.Some of your customers, such as charities or churches, will be exempt from taxes. Thesecustomers will need to provide proof of their tax exemption, and your commerce system willneed 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 RequirementsSince “the cloud” implies that your service can be used from anywhere, you will need to decidewhether international customers can sign-up for your service. If so, you will need a system thatsupports 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 thecountries where you primarily do business.13 Conclusion “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 MicrosystemsWe hope that this Zuora blueprint has provided you with a good sense of all the business modelconsiderations you will need to make before launching your cloud offering. Of course, not all ofthe items outlined in this document may be applicable for your business, but chances are thatmany of them will be.If you feel intimidated by all the work that remains in front of you, then you are not alone. Mostof the leading vendors that Zuora has helped launch into the cloud have faced similarchallenges. By reading this blueprint, you at least have an early start in thinking through yourcloud business model from end-to-end, reducing the likelihood that when your cloud technologyoffering 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© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 18 of 19
    • Zuora Blueprint for the Cloudyou are also not alone. Most of Zuora’s cloud customers reached out to us when they hit thewall with their traditional ERP or legacy systems and realized that a further customization effortwould be too costly and daunting.In any event, we invite you to contact Zuora to learn more. As the leader in subscription billingand cloud commerce, we are interested to hear about your business and discuss how apartnership with Zuora might accelerate your path to the cloud.© 2010, Zuora Inc. All Rights Reserved. Unauthorized reproduction is strictly prohibited. Page 19 of 19