Monetizing SaaS: Present Trends and Future Outlook

How we increased the capacity of our platform by 500% without any additional hardware

2011-01-28T04:47:00.000-08:00

Introduction:

Functionality:

Functionally, our platform is a geared towards the BPO space where it can handle the data and metadata related to all kinds of tickets / tasks that agents / supervisors in a BPO are supposed to take up (this includes voice, chat etc). As such it interacts with various other internal / third-party sub-systems including Telephony Platforms, CMSs, Key Management appliances etc. The platform is also responsible for tracking the real time states of the agents and handle task / ticket allocation and other notifications. Finally it also enables monitoring of and reporting on everything.

Architecture:

Architecturally, for scalability, the platform is vertically partitioned into applications that serve different kinds of needs - separate applications / vertical partitions for data / call processing, others for metadata processing, agent management, SSO, authentication and agent skill group matching etc. These applications share a common replicated database (MySQL) and share other infrastructural components like ActiveMQ for Messaging and Memcached for caching etc. The entire setup in installed on two quadcore servers which are in a high availability configuration. This setup then becomes the shared-nothing topology that we clone at different locations (or whenever we need additional capacity).

Additionally, from a fault tolerance and scalability perspective, we process some critical CPU intensive tasks in a highly federated manner - so all voice recordings are done on the agent desktops - and both data as well as metadata are initially cached there. As such, even if the entire platform fails (and only the telephony platform is available), the agent is still able to take / make calls (something that is mission critical from a BPO perspective) - the data and metadata gets transmitted to our platform when it recovers from the fault. Reconciliation mechanisms are built in.

The Problem:

The platform (with the current hardware setup of two quadcore servers in HA configuration) had been certified to take a load of 60,000 calls a day with a safety factor of 25% ... things start slowing down after that. The business however expanded exponentially, and we started getting over 95,000 calls a day. To compound things, two thirds of the calls started coming in an 9 hour interval ... and business was still growing. This stretched the infrastructure that we had provisioned to the limits - things started getting delayed - resulting in backlogs - business started getting impacted.

Adding additional hardware (in a shared-nothing topology) would have been the quickest solution - alas, the entire setup was running in our data center ... and getting more hardware meant direct purchase / rent ... and the entire PROCESS (with all its authorizations / formalities etc.) takes time. And given the fact that we were planning to move to a hosted setup, business stakeholders were not too amenable to procuring more hardware.

The Solution:

We decided to "improve within the constraints".

To be able to improve any of the non functional characteristics of any system, you first need to understand the usage pattern of the platform and then to find how these define the bounds of the system.

We re-profiled the system and found that the bounds of the system had completely changed (from the original measures). The DB was causing problems, but the situation of the application server was even more aggravated - especially from a threads perspective. All the HTTP threads that we had provisioned for the application were being used all the time - and as such new requests could not be served. The number of messages passing through ActiveMQ were so high that we got a producer consumer problem - the consumers were not able to consume as fast as the rate at which producers were sending messages. Finally, because of the variability of the call traffic, there were times when the systems was absolutely chocked - so the fault tolerance kicked in and data / metadata started being cached at the agent end - and there were lean periods when the infrastructure was barely used at all.

We also realized that a small slowdown of the DB compounded problems. Since the request rate was the same, if the request processing rate went down, all the HTTP threads got used up - and new requests were denied - some of these were critical requests - and their denial cause bigger issues within the system.

Also, based on some usage patterns of the application, we realized that the business did nor need ABSOLUTELY real time information - some delay was permissible. There were only a couple of instances where real time information was critical.

After brainstorming, we created a laundry list of things that we could do. We did not create a plan ... we just started going after the things that were either low hanging fruit or could give us the biggest impact (everything else would have to wait until the initial set was completed, deployed in production and the system re-profiled to check the bounds / constraints - so we used a pull based iterative approach).

We decided to REDUCE / PRIORITIZE / ASYNCHRONIZE / BATCH !!

1. Based on the retention policy for various customers, we reduced data in the primary tables - shifted these to archive tables.
2. We re-partitioned the system to take critical real time functionality out as separate modules and gave them dedicated resources (threads / DB Connections / Memory / CPU) thereby prioritizing the real time activities.
3. Reduced the number of updates / messages being sent to the platform - this was done by rationalizing based on need - if a real-time update was not necessary, it was cached and then sent as a batch.
4. We made a lot of operations with the system asynchronous - anything that could wait was a candidate - tasks were queued up and processed in reasonable batches (and these parameters could be fine tuned at runtime) - this brought in predictability into the system (and smoothed the peaks / troughs in the call / request traffic).

Six resources .... one month down the line ... four incremental production releases later ...

We continue to use the same hardware resources ..
We continue to have the same traffic ...
But ...... the platform handles all of this without a glitch. In fact it handles it at such a pace, that even though we asynchronized a lot of tasks, to most users, it appears to process things almost in real time. After re-profiling the system, the capacity of same two servers now stands at 3,00,000 calls a day with a safety factor or 15%. That's a whopping 500% increase.

Not that there is no scope for more improvement ... quite a few things still remain in the original laundry list of things that we drew up. Some of them have become redundant in the current context, because after re-profiling the system, the bounds / constraints of the system have changed ... but others are still pretty relevant. However, the current capacity of the system is much above what's required by the business - so the focus has now shifted to features / radical functional changes that enhance the user experience / marketability / consumption of the platform in a SaaS based manner .... but that's probably for another blog post...

ROI

From an ROI perspective here are some numbers:

Cost incurred: INR 6,50,000 (roughly the cost of resources for 1 month)
Rental Price Of Two Servers (option that we were considering earleir): INR 47,000
Break-even in less than 14 months (given that the business does not grow / more capacity not required)
If business grows and utilizes the full capacity - then break-even happens in less than 3 months
Given the fact that this same setup is deployed in 4 different locations - if business grows in all 4 and utilizes capacity - then break-even happens in less than a month!

More importantly, from a multi-tenant delivery persective in a SaaS environment, the capacity increase signifies that we can be more competitive (can drop prices per transaction / license) - or we can enjoy better margins at the same price points.

Guess we've kept the promise of unshalking the business from technological / infrastructural constraints ... now for the business to deliver on its promises ...!! :-)

Monetizing Software As A Service (SaaS): Present Trends and Future Outlook

2008-02-29T02:49:00.000-08:00

Introduction

There’s been a lot of talk on SaaS (Software as a Service) having reached the tipping point in the year 2007, and 2008 is being a watershed year that will actually see a proliferation of SaaS offerings and platforms and lot more players including telcos capitalizing on it.

However, the business model for SaaS has still not been perfected – organizations still struggle with how to monetize the offerings, how it will impact the cash flows and how to cope with the financial impact related to transitioning from the software product model to Software As a Service model both for themselves as well as for the channels (traditional as well as non-traditional) as highlighted in this blog by Ken Rudin (from Siebel). This sentiment is also echoed in a comment from Larry Ellison stating – and I quote “SaaS is very interesting but so far, no one has figured out how to make any money at it”.

This article strives to de-mistify the ways in which organizations can create viable business models around SaaS and effectively monetize the offerings that they may have. It also illustrates these options with examples from the real world on how companies have priced offerings.

This article also highlights some of the pre-requisites for effective monetization of SaaS and postulates how the SaaS monetization will evolve over a period of time as the market matures, thereby giving a futuristic outlook which might help organizations take strategic planning positions.

Pre-Requisites to SaaS Monetization

Although these cannot be directly categorized as monetization strategies, there are certain pre-requisites without which SaaS monetization will not take off or the profitability will be severely restricted and scaling up will not be possible. These are covered under this section of pre-requisites.

Rework The Sales Commissions / Targets

Rework the sales commissions? Now how could that be related to the monetization of SaaS? As distant as it might seem, it is one of the most significant (although indirect) aspect that may have an implication on your SaaS revenues (especially if there is a transitioning from a license based model). Why would a sales rep hardsell a $75 per user per month deal, and give up commissions for what could have been a multi-million dollar license deal? Why would senior sales execs promote SaaS if that does not help him meet the targets for a quarter (license based deals would help them recognize the same numbers quicker)?

The key to this shift is to re-work the sales commissions so that they are more in line with insurance agent commissions (where the actual revenue generation for the deal happens over a period of time but bigger sales commissions are paid upfront in recognition of this revenue generation potential). Quarterly targets for sales should also be reworked to factor these in. If these are not appropriately tweaked, the company transitioning to the SaaS model will never get a buy-in from the sales force and efforts to monetize the SaaS initiative will fail right at the outset. So this should be considered a pre-requisite.

Multi-Tenancy

One key aspect that the SaaS providers need to take care of is that the have a multi-tenant environment (such that they can serve out the service for multiple customers out of the same instance) – there may be different kinds of concerns for different kinds of customers while doing this.

Multi-tenancy by itself is not a monetizing strategy. It is more a requirement from the point of view of cutting costs (thereby increasing the profitability). Another pre-requisite when we consider multi-tenancy perspectives is to provide configurability to suit customer needs (and be more attractive and scalable (from an on-boarding point of view)). As such, these aspects become critical – if vendors can share a virtualized infrastructure among various customers, the profitability increases exponentially.

Specific Monetization Strategies

Some of the ways in which SaaS offerings can be monetized are as follows:

Advertisement Revenues

Typically providers have tried to use this revenue stream to monetize offerings where there are high volumes (number of users) and cost of providing the service is less per unit. Sometimes, providers have even given the service for free capitalizing on the ad revenue … Google being the classic case. This enables vendors to go after the proverbial “Long Tail”. However, this may apply to only specific cases, for most offerings, this may not be a viable option (if used as the only revenue stream). Also, in such cases, the vendor will have to make sure that not only are there sufficient “Eyeballs” but the users are also glued to the application for a longer period (and to achieve this stickiness, will have to provide suitable enticements). Ad. revenue may, however, have to be supplemented in conjunction with other revenue generating mechanisms – pure play Ad. revenue vendors may not be profitable unless the they have a very strong business model. Google Apps is a case in point. However even Google has premium offerings of the same services for a price (example they have Postini services which are part of Google Apps Premier Edition (GAPE) for a price. This even has a differentiated Gmail offering that has an SLA of 99.99% uptime that comes at a premium). Another viable way to supplement the attractiveness of the offering (in this B2C sphere) is to augment the social computing framework – allowing users communities to collaborate in the same space (while providing the SaaS offering). The community sharing / collaboration itself can be made a premium feature (or can be used just to augment the stickiness). Examples of this include the SaaS offerings from BowTie.

Subscription Revenues

This has by far been one of the most potent revenue streams for most providers – and dates back to the days of the ASPs. In this case, the provider gives out the service to users on a subscription basis – which may be of varying durations, and charges a fee for the subscription. There are various flavors of this that are in vogue and have been listed out:

One time setup fee: This may apply to cases where there is a fixed cost that the provider might need to bear while giving the service to the user (typically this is not the case). This is also the easiest to implement from a product perspective. This is the closest to the licensing model (and does not quite fit in with the SaaS model) and has been listed here because there are some cases where the there may be a big setup fee (in which case this would apply – but typically in conjunction with one or more recurring fee as indicated below). Examples of this kind of pricing is Amazon’s EC2 and S3 services (which uses a combination of fixed installation and variable usage based fee).

Fixed subscription fee for specified lock-in periods: This is a mode that is being used the most as of now. In this case, the subscriber is charged a particular fee for a particular period (the fee is charged regardless of whether the user avails of the service or not). Examples include Symantec Online Backup and Storage services. This is also easy to build into the offering as most billing systems support this kind of pricing model.

Usage / transaction based pricing: This is the opposite of the fixed subscription fee. Here the user activation (for using that service) may be done for free and the user is charged only based on the number of times the service is accessed or the duration for which the service is accessed. This is a typical model used while monetizing WebServices (Examples include web services at StrikeIron). Since SaaS offerings will typically be hosted by the provider, the usage will typically have lean and peak hours (and there can be huge variances based on usage). If the provider opts for a usage based revenue / pricing model, then it will typically need to provide variable (less) pricing at off peak hours (a chapter taken out of the telco books) so that the infrastructure is utilized in a more uniform and profitable way (while still maintaining the SLAs) and also lowering the entry barriers for the more price sensitive customers. This kind of pricing model is harder to build into the system because not only does it involve metering / usage (which will have to be built into the service offering), it also entails variability of price and this kind of pricing is supported by only the most complex (and expensive) billing engines (through customized workflows / pricing models). Telcos have mastered this kind of pricing for their telephony services – similar principles can be applied to software services.

Volume based pricing: In such cases, the volume of use governs the prices. If the volume is high, then the cost per unit declines (and vice versa). This kind of pricing attracts the higher volume customers. A variant of this is when providers create multiple offerings for the same service (differentiated by volume of use) and price these separately and also provide an upgrade path between the offers – this methodology is halfway between the fixed fee based subscriptions and the volume based pricing.

Component based granular pricing: This kind of strategy can be used if the service offering itself can be broken down into multiple sub parts (that work in tandem), and each component is priced based on usage. An example of this is the Amazon EC2 and S3 services which both work in tandem (EC2 in itself cannot work without S3) and both these are priced separately based on the metered usage (and this also has a variation based on the volume of use / data transfer).

Non-Standard Rates

SaaS providers will also need to have the flexibility to provide non-standard rates (both fixed and variable) to specific customers (especially for large accounts) while preserving the main monetization base. Flexibility to do this would mean that vendors will be able to come out with unique value propositions for customers. This has already been highlighted to an extent in transaction / usage based pricing as well as volume based pricing. However, this point just highlights that the flexibility should be built into other pricing variables as well. Additional flavors related to flexible pricing may include aspects like overages (over and above a specific quota that may be governed by the subscription / plan) that may be charged at a different (higher) rate.

Bundle Offerings / Target Specific Market Segments

This is the avenue that is fast becoming the new mantra for success in the contemporary world as vanilla offers fail to find favor with customers. In such cases the provider bundles the offering with complementary / supplementary offerings which may be in line with the customers’ profile / use (or customizes the offering for a specific market segment so as to serve the niche. Example: Verticals OnDemand). The bundle is typically priced less than the sum of the prices for the individual offerings. In such cases, not only does the provider leverage the main offering to sell additional offerings, he also tends to provide a complete solution to the customer, and is not relegated to selling a standalone service. This also creates a host of up-sell / cross-sell opportunities in case the provider sells both the individual offerings as well as bundles them together as bundle offerings (targeted at a particular segment) and also offers an upgrade path from services to bundles. This also creates opportunities to “verticalize” the SaaS bundle towards a target segment. This is one strategy which is being touted by Netsuite.

Value Added Offerings / Convergence

Customers no longer want to buy silo applications / services. It has been noticed that increasingly, the purchase decisions are based on whether vendors are able to offer complete solutions. To surmount this vendors will need to provide value added offerings with the service / bundle offerings. These may span differentiated SLAs, analytics, support, training, hosting and hardware all bundled together as one package deal or in combinations thereof.

Lower The Barriers

Lower the entry barriers for customers / channels. SaaS is all about lowering entry (and exit) barriers (relating to investment (CapEx), infrastructure (hardware / software), administration (configuration / ongoing maintenance / support) etc.). Vendors need to lower these barriers so as to create “low hanging fruit”. Vendors also need to provide the try and buy option – where the user can try the service for free for a specified time period and subsequently subscribe to the offering (although the provider will incur a cost for this, its should be considered part of the customer acquisition cost). If the entry barriers can be reduced sufficiently, the conversion rate will be higher. However, to cash in on the conversion rate, vendors need to also provide multiple levels of the same offerings that are sufficiently differentiated and provide a noticeable value add so that the customer can be made to upgrade, and the provider can move up the value chain. Examples include Google cutting the pricing of Postini related services drastically. Other examples are also noticed in the OpSource’s Success-Based Pricing(SM), a unit-based pricing model that allows businesses to begin with a modest minimum commitment and scale expenses as revenues increase. Another variant is Jamcrackers iStore initiative that charges a fixed amount for an iStore instance and then provides for a revenue sharing model.

Channel Enable the Service Offering

Channels are becoming more and more important – go it alone strategies have been found to limit growth – customers tend to go through the VARs who have historically provided them with hardware / software offerings and related support. Until SaaS offerings become a commodity, it will be prudent for the vendors to leverage the VARs who have already developed trust relationships and brand equity with the customers. As such, vendors should enable channel participation and be able to define the commission structure at each level into the offering. The commission structure itself can be differentiated and may contain variations (discussing these is beyond the scope of this article).

Transitioning Capability Complementing Multi-Tenancy

Over and beyond this providing for multi-tenancy, providers must also plan and provide for the transitioning of these customers from one environment to another. This is required from two perspectives:

To guarantee better (or degraded) SLAs – as specified in the earlier point.
If required to transition the customer to their own (private) data center (this may be required when the customer grows very big and wants to cut the costs by utilizing some of their own infrastructure).

This transitioning capability (within the multi-tenant environment) can be used to further monetize SaaS offerings.

Become Aggregators (or use aggregators)

The infrastructure that is required for supporting SaaS is complex and comes at a cost. If this can be apportioned across multiple providers / vendors by becoming (or using) aggregators, then the breakeven will be quicker (and for those using the aggregator, the time-to-market / time-to-revenue will also be faster) because of reduced cost per unit. Also, becoming (or using) an aggregator model has its advantages that vendors can bundle offerings with complementary offerings from other vendors thus increasing the attractiveness from a consumer standpoint. In addition to this there is also a move to create SaaS applications that are themselves built on SaaS as highlighted in this post. This too will accelerate the monetization of SaaS (and applies more to smaller players).

Emergence of Development and Runtime Platforms / Marketplaces

Complete development and runtime platforms as well as aggregated marketplaces for SaaS offerings will also become the equivalents of technology / market clusters / eco-systems – a kind of one stop shop for all customers needs, thereby aiding in the choice. The development / runtime platforms (like force.com from SFDC and Coghead 2.0 from Coghead) will allow accelerated creation of SaaS offerings and also aid in standardization of data and processes so that offerings from multiple vendors can co-operate in a seamless fashion and can also lead to the creation of Mashups (however this still seems to be some way off). These platforms / marketplaces will become ubiquitous as SaaS proliferates. These platforms / marketplaces can then monetize their infrastructural services akin to how eBay or Amazon monetize their platforms – get a certain amount for listing and a %age of sales revenue. The profitability and attractiveness will depend on the scale of operations. Future trends may also include these clusters collaborating with each other to form alliances (similar to the airlines model) so as to leverage each other’s strengths and provide a unified view to the prospective customers (this is however contingent to standardization measures that will lead to greater interoperability).

Vertically Integrated Marketplaces / SaaS Platforms

Platforms / marketplaces that achieve a critical mass might also benefit from vertically integrating (backward and forward integration). Example: owning the data centers that host the platform (backwards integration), running marketing / sales programs for the stakeholders in the marketplace (including vendors and resellers) (forward integration). By doing this, they will be able to straddle the complete value chain and be in a better position to generate revenue at each stage (the key here is that the marketplace / platform provider should have reached a critical mass - such that the cost of owning the upstream and downstream parts of the value chain is offset by the revenue generated by these parts). A classic case of this is SFDC (SalesForce.Com) – although even it still would need a bigger subscriber base to fully capitalize on this. Master brands (if and when they transition to SaaS) would probably go this route as the market matures.

Professional Services

Since SaaS would typically be hosted by the provider / third party, it would be almost natural to deduce that professional services would not necessarily apply. That would ideally be the case (in case the service that is being provided is infinitely customizable by the user). However, the reality is very different. Most SaaS offerings are not customizable to the extent necessary (out of the box). Vendors should provide hooks into the SaaS offerings so that they can be customized to suit the needs of specific users and then provide their professional services to monetize the offering customization. This will apply for specific complex cases. Vendors should not take this as an excuse to limit the offering flexibility. The flexibility is required and wherever possible, the functionality should be configurable. Professional Services / support should be utilized for catering to very specific needs. Also, since currently there are no standards governing SaaS integration, the integration of SaaS offerings (a complex problem) with the customers’ existing infrastructure / applications also forms a big market (that creates professional services opporttunities). Similar monetization possibilities also exist in handover of turnkey offerings and un-subscription related exit barriers (where a client requires the data). If product vendors wish to concentrate on the product (and not be bothered about customization through professional services), they could still monetize the phenomenon by tying up with a third party for this and charging the third party a customer referral amount.

Turnkey Offerings with BOT

Customers, especially the bigger ones (enterprise class), unfamiliar with the SaaS offerings are looking more and more for turnkey solutions. These same customers might want to manage individual parts themselves at a later point of time as the comfort level increases and as and when the costs of use outsourcing the different functions becomes sufficiently high (when the number of subscriptions becomes high). This may also be required from a security perspective by customers having concerns relating to data privacy and security or those bound by regulatory compliance issues. Vendors might also want to add such transitioning mechanisms and monetize the same on a BOT (Build-Operate-Transfer) basis – this applies to larger customers. SMBs may prefer complete outsourcing of the solution (rather than a turnkey / BOT one).

Conclusion

There are many ways to generate revenue in a SaaS based model – each with their own applicability, attractiveness and implications (architectural, financial and business).

One of the biggest changes is that there is a clear shift from getting immediate revenue (license fee) at particular points of time, to generating a revenue stream that creates extended and sometimes difficult-to-predict cash-flows over a period of time. Clearly the risk shifts to the vendor in such cases – and customer success gets translated into vendor success in a more pronounced fashion.

There is also an overwhelming need for the roles of partners / channels in this whole paradigm shift. Contrary to the perceptions / concerns that SaaS will tend to replace the channel as well as the SI (Service Integrator) partners, in actuality these partnerships will still be very much required and add considerable value – only, the manner in which these partnerships are leveraged and monetized will change and the nature of value addition will evolve.

However, these fundamental paradigm shifts should also be viewed as a huge opportunity as SaaS shifts from becoming a disruptor to entering the mainstream in the year 2008. Those organizations that are able to master this shift will be in the position to capitalize on the $19.3 Billion market and forever change the competitive landscape – according to Gartner, 25 % of New Business Software will be delivered as Software As A Service by the year 2011.