Problem solve Get help with specific problems with your technologies, process and projects.

Selling SaaS: Operational requirements for consumers vs. businesses

The key to successfully selling SaaS across all market segments is addressing the different operational requirements among various buyer groups.

Cloud providers have long divided their potential market into three segments: consumers, small and medium-sized businesses (SMBs), and enterprises. While this segmentation seems to apply to all categories of cloud services, operators are finding that consumers and SMBs in particular often can't manage a cloud migration or support their applications in the cloud without professional technical assistance. This often increases the cost of cloud computing beyond the level where migration is justified. But Software as a Service is easily consumed by every class of cloud customer prospect, and SaaS also has the best overall profit margins.

The key to successfully selling Software as a Service (SaaS) across all market segments is recognizing and addressing the different operational requirements among different buyer groups, which often stem from the value propositions that drive SaaS in the consumer, SMB and enterprise market segments.

Consumer SaaS opportunities are typically associated with services rather than software. The user purchases something like home monitoring, and it is implemented using SaaS principles from a cloud platform. In this case, SaaS is fulfilling a need the consumer naturally thinks of in terms of a hosted service, and in most cases the consumer will be using the service intermittently rather than regularly. A consumer's willingness to pay for the service, rather than the alternative of buying and hosting it themselves, sets the price.

For scalability, providers need to enable cloud bursting operations or load balancing in the cloud at load levels often found in enterprises.

SMB SaaS opportunities are almost always linked to specialized vertical or horizontal software applications that buyers could obtain by purchasing software and deploying it on their own hardware. Their justification for SaaS is typically based on lower capital costs, easier application support and improved cash flow. Unlike consumers, SMBs are likely to use SaaS every day and build business practices around them.

Enterprises SaaS opportunities are most often linked to the need to support key workers with application tools. In nearly all cases, these tools are available as software installed in-house. Users may reject that choice because they want to bypass IT department interference or because the requirements for the software don't match internal platform commitments. The level and frequency of use of these applications varies significantly from application to application, as does the skill level of the user.

SaaS operational requirements for different customer types

With consumer applications, the key operational requirements for cloud providers to understand are to support service functionality even when service access is constrained, provide a rich and capable self-support portal to contain operations costs and watch economies of scale carefully to ensure that operations costs for the overall service grow more slowly than the revenues from it.

Consumer SaaS operational requirements. Consumer SaaS architectures are best seen as two-layer structures with a Web-portal front end -- providing customer parameters, service control and support -- and a back-end application process to manage service telemetry. Operators report that the service operations of consumer SaaS are most like those of voice services administration. It is critical not to lose call records, but users can tolerate brief periods when they can't access their accounts. Service components that record essentials like customer equipment status, security status, and the like, must be fully redundant and load balanced to ensure they can scale to demand, even if the front-end processes are overloaded or fail.

When there are portal problems, it's important to be able to provide notice of a problem, along with the time of expected resolution. Without that, consumers begin to make calls to billing and support numbers to get information, which raises operations costs and burdens call centers significantly. Some operators will have the URLs for customer support and portal failover to a standard HTML page to provide that information and avoid problem escalation and cost overruns.

Operational requirements for the SMB. Application design is likely the key to success in the SMB SaaS market. Web development practices have demonstrated that the most scalable and reliable software architecture is the RESTful architecture of the Web, where each application service is a Web service represented by a URL. It is the responsibility of the client device to preserve context ("maintain state") during multiphase exchanges or transactions. This architecture allows each application service to be load balanced and redundant with minimal risk of information loss or database integrity. Databases are the vulnerable point in these configurations, so database reliability and integrity controls must be especially strong for SMB SaaS.

For the SMB, there is no aspect of SaaS where even short periods of failure will be tolerable, and so it's critical that service reliability be high. In fact, SMBs typically have a lower tolerance than enterprises for service failures because the SaaS software is often directly tied to their key business operations -- especially if it's vertical-market software managing their whole business. Cloud providers often sell SMB software through third-party developers, and problems with the SaaS form of the software will create issues of developer loyalty.

Operational requirements for enterprise SaaS. Sharing some similarities to the other markets, enterprise SaaS can include both the telemetry and portal duality of consumer SaaS and the high-availability needs of SMB SaaS. But it generates additional issues in security and the scalability of services. On the security side, the big issue is in securing integrated SaaS applications. For scalability, providers need to enable cloud bursting or load balancing in the cloud at load levels often found in enterprises.

Many enterprise applications use front-end handlers to present customized views of information to workers, and this process can create a security headache when it's applied to SaaS. It is important to ensure that failure recovery processes don't create a means whereby a so-called "Trojan application programming interface (API)" can be inserted into an application to gain access to company data. Cloud providers need to ensure that their enterprise SaaS APIs can be authenticated by the buyers' application integration tools to prevent a security or compliance problem.

In load balancing, the general rules on RESTful interfaces are important and applicable to enterprises as well as to SMBs, but enterprise data volumes for some SaaS applications may create both pricing and operations challenges. One way of managing this is to store all SaaS application data in high-availability appliances or on hardened servers, and use a query -- Relational Database Management System (RDBMS) as a Service -- interface to the database, rather than a standard block or cloud I/O interface. This will reduce transaction volume and network traffic, making it easier to manage Quality of Service effectively.

The bottom line is that the operations of all cloud services depend on effective management tools and good management visibility. Each of these strategies will need to be applied in that context to be fully effective. If cloud providers have the right tools and understand the operational requirements for different customer sets, SaaS can be sustained profitably for all classes of buyers.

More on selling SaaS

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.

This was last published in September 2013

Dig Deeper on Telecommunication networking