Questions & Answers from Rackspace Webinar

More than 100 people attended the webinar sponsored by Rackspace. Below is a listing of answers to the questions people raised...

B2B seems to be much more sensitive about security than B2C. Does that match with the price pressures you experience?

I agree security is more important for B2B when you leave out B2C financial transactions. I haven't seen anyone extract a premium for providing higher levels of security. One reason may be the only way to get a premium for a product that offers "high" security is to offer a less expensive "low" security version of the same product. By offering a "low" security option, you might not get the deal because you create confusion -- or worse -- doubt.

Do customers value must-take upgrades when there is good communication of the changes that are coming so customers can prepare with documentation, training, etc.?

Must-take upgrades and changes allows a vendor to maintain a single code base. This can can be good for some customers but maybe not for all. Customer satisfaction can suffer if your upgrades and changes don't fix problems or add asked-for functionality. Furthermore, customers who are integrating your cloud-delivered product with other applications or business processes may value stability and predictability over anything new. I once heard the CIO of Citibank tell a bunch of technologists that making changes in technology is as desirable as changing the engines of a 747 in flight.

What do you mean by Freemium? Does freemium also include 30 day trials?

The term "freemium" is pretty murky. In this presentation any product that is free for a limited time is a trial. If a product is offered for free when a prospect stays within certain usage limits could be freemium or a trial depending on how restrictive the limits may be. If a prospects can easily stay within specific limits and derive value, then this is freemium (e.g. on-line storage offering a 5 GB limit which is plenty for many people). E-mail services that restrict you to a small e-mail list or a single project is a trial because the mail list size or number of projects is well below what most people will want to use.

Does offering a feature for a small add-on fee qualify as an upgrade or an upsell when developing a financial model?

When you develop a financial model for a SaaS / Cloud business, you need to model the amount you get from customers. If a customer is paying you more money by upgrading to a higher priced version of the product or by adding an option doesn't matter. What does matter is when the change takes place. The financial model mentioned in the webinar looks at cohorts (people that came on board at a point in time) and when they changed their spend relative to the entry level amount.

How do you suggest dealing with customers that will not upgrade when an upgrade is released?

First, when a customer logs onto a cloud-based app, the app is the app. In this case, the customer doesn't have a choice. However, if a substantial part of your customer base resists new features (presumably they do want the bug fixes) then you may want to offer a different edition for people who are satisfied with the functionality at a point in time. To avoid foisting something unwanted on your customers, give them plenty of warning in advance of the change. Don't forget to remind them of the benefit of a cloud-based app -- always being at the current rev level without having to mess with upgrades.

Is it important to localise pricing currencies?

Probably not... You may want to provide a currency converter so someone knows the cost in their local currency but credit cards do the currency exchange as a matter of course (for a price). Since the worldwide web is just that, worldwide, there isn't anything wrong in providing a worldwide single price. The only problem is the exchange rate and local competition may take its toll on your sales. Don't worry about multi-currency pricing until you are bigger and the lost sales and foreign exchange costs are in the millions.

Any recommendations on SaaS billing/reporting systems for complex enterprise offerings?

There are a number of systems out there: Aria Systems, Zuora, Vindicia, RevX, among others. I can't vouch for how well these systems work in a given situation or how easy they are to integrate into your application. I think most cloud software companies are better off finding a hoster who provides a complete stack of software, including billing, so you can focus on developing your application rather than integrating your application with another app.

If you take the cost of designing software, figure out how many customers you would get over some timeframe, can this be used to figure out how to price an application?

I would advise against pricing your software that way for a couple of reasons. First, the number of customers will be a function of the price level and the features that are associated with that price. Therefore, decide on what the deliverable will be and assess the value delivered to your customers and the price you will charge. Second, your costs are a reflection of your ability to manage your costs and is YOUR problem -- not your customer's. Your costs do count when it comes to assessing profitability or your company's viability. Find a package and a price level that provides good value to your customers and then see whether there will be enough volume to stay in business. If not, add more value to justify a higher price point. If that doesn't work, reconsider the whole project.

Should customers expect different rates/prices for different types of cloud offerings - public, private, hybrid, etc?

The only thing that matters to customers is the application. If a particular delivery mechanism offers different value (e.g. reliability, control) then the prices can be different but only if the difference is noticeable or can be made that way..

What guidance can you provide in balancing free feature enhancements/releases in SaaS vs. monetizing them?

The software industry is blessed (or cursed) with two characteristics: first, everything is changing; second, everyone expects ande gets more for less as time goes on. Therefore, you may need to constantly add features to increase value delivered just to stay where you are on the technology treadmill. If your new features have enough appeal, you may be able to charge for them. It is not unusual for what was the top-of-the-line edition to become a mid-range offering and the previous mid-range offering to become the entry-level product.

When bringing a product to market in the B2B space, if you price according to the real value, it lengthens the sales cycle, and increases politics of the decision making. How do you get in?

No question about it: Higher prices make sales harder. However, customers who pay more tend to be more committed and therefore loyal. If you offer easy-to-use trials, you can accelerate the product evaluation. An enterprise-wide sale by definition is more complex and will take longer because of the size of the transaction and the implementation risk -- not usually the unit price of the product.

Do you have any recommendations for what to do with the training costs for a product? Do people want to see the training costs broken out separately or wrapped up in the price?

If you and your customer recognize training costs are high, you may be better off charging separately. If your application requires a lot of implementation services you may want to bury training in with the implementation services. If you can use on-line, canned training modules then you may want to provide them for free. Of course, you need to be careful about the impact on support if your customers are poorly trained.

Do you have any specific recommendations for moving an installed base of customers from perpetual/subscription licensing to SaaS?

First, I'd look at whether you really need or want to mess with customers who OWN perpetual rights-to-use. If the issue is maintaining a single code base, you may want to have them install the multi-tenant version and provide you with access so you can push mandatory upgrades. Another alternative is to obsolete the on-premise product. (Be careful with end of life issues...) One tactic I have seen is to let the customer use the SaaS version for the same maintenance and support fee (and configuration). Over a pre-negotiated period of time, you can migrate the customer to higher prices and functionality that are only available on the SaaS version.

How do you suggest a company which is new to SaaS go about establishing their prices

Well, you can always attend one of our workshops... But I suggest you really get to know your customers and their businesses. In particular, take a look at what drive your customers' businesses. Understanding the "value drivers" of your customers will let you select the right metric to charge for and will allow you to understand the economic value being delivered from which a price can be derived.

Join our maillist