Z commerce-for-the-cloud-blueprint

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

June 2010

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

Zuora Blueprint for the Cloud

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

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


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 Overview
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 Pricing and Packaging
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 Usage Processing
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 Billing
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 Payments
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 Account Management
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 Subscription Management
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 Web Self-Service
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 Advanced Commerce Models
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.

10 Reporting and Metrics
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.

11 Accounting System Integration
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.

12 Other Functionality
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.

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 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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Z commerce-for-the-cloud-blueprint

Similar a Z commerce-for-the-cloud-blueprint (20)

Último

Último (20)

Z commerce-for-the-cloud-blueprint