Content uploaded by Marco Spruit
Author content
All content in this area was uploaded by Marco Spruit on May 10, 2016
Content may be subject to copyright.
154
Copyright © 2011, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Chapter 10
Software as a Service and the
Pricing Strategy for Vendors
Nizar Abdat
Utrecht University, The Netherlands
Marco Spruit
Utrecht University, The Netherlands
Menne Bos
Accenture, The Netherlands
This chapter describes the diverse aspects of
Software as a Service, which makes it valuable
for many different readers. It starts with the back-
ground of SaaS, followed by its definition and main
characteristics. Next to that, we show how readers
can see SaaS differently from traditional software
and how it is interrelated to other technologies such
as cloud computing, Web 2.0, Application Service
Provider (ASP), and Software plus Services (S+S).
The benefits and risks of adopting SaaS from
different literatures will also be compared and
explained in detail. In addition, we will present
several scenarios for how SaaS is currently being
delivered in the market and introduce our Pricing
Strategy Guideline Framework (PSGF). In this
chapter, several new deliverables that are produced
during our studies and interviews with nineteen
different SaaS companies will be presented. The
Software as a Service (SaaS) has been a dominant information technology (IT) news topic over the
last few years. It is a new phenomenon where software as a digital product, instead of being locally
installed and delivered as a product, has been shifted to being installed in data centers and delivered
as a service. The users do not need to worry about the installation and maintenance of their software
since these tasks have now become the responsibility of the vendor. In reality, many people are still
puzzled about SaaS with other new technologies. Next to that, there are numerous enterprise users who
hesitate to adopt SaaS solutions because of the idea of storing data outside their company. This chapter
elaborates on the state-of-the-art of SaaS from both scientic and business perspectives to help readers
better understand this technology.
DOI: 10.4018/978-1-61692-877-3.ch010
155
Software as a Service and the Pricing Strategy for Vendors
main deliverable itself is the PSGF framework
which aims at providing SaaS vendors with a set
of guidelines to ensure that all the fundamental
elements with respect to pricing are included in
their pricing strategy. Our framework will be useful
especially for small-to-medium SaaS vendors –
particularly the startup vendors, which tend to have
less experience in pricing their SaaS solutions and
dealing with several issues in the aforementioned
scenarios like low sales cycles, chaotic pricing,
and entering a new market segment (Geisman &
Nelson, 2008). The framework including all lay-
ers and elements will be described in detail with
several examples as well. Our framework has
been constructed from several existing theories
and has been successfully validated by a number
of experts in the field.
Several contributions from both scientific and
business perspectives are conveyed from this book
chapter. From the scientific perspective, the matri-
ces of SaaS key principles and SaaS benefits and
risks, which also specify to which groups they are
applied, certainly add value to the existing SaaS
literature. Furthermore, the six scenarios intro-
duced in this chapter have never been examined
in previous SaaS studies. However, this chapter’s
most significant contribution is the framework
itself, as this research presents the first SaaS pric-
ing framework available. In most of the available
academic software pricing literature, authors are
using mathematical formulas, whereas this book
chapter does not, making it more favorable to
readers. Finally, from a practical business point
of view, our framework presents all fundamental
elements related to the pricing of SaaS solutions
which is very likely to be quite useful for many
SaaS vendors.
’Software’ is a general term used to describe
the computer programs, procedures, rules, and
the associated documentation, in relation to the
operation of a computer system which are stored
in a read/write memory unit as part of the digital
system (Langholz, et al., 1998; Wordreference.
com, 2009). This term was first introduced by
Tukey (1958), and has become an integral element
of the English language and has been included
in many other languages. At that time, when the
computer era began, the manufacturer sold the
computer as a physical machine, which included
the operating system and rudimentary software
at no additional cost. This situation has changed
after IBM announced on June 23, 1969, that it
would unbundle the hardware and software in the
future. Later on, this has been seen as the birth
date of the software industry as we know today
(Kittlaus & Clough, 2009). Within a few decades
the software market has dramatically grown.
From that time until today, in most situations,
customers are required to buy the software li-
cense, install and run the software on their local
computer or server before they can use it. The
installation files can be stored on CDs or other
storage devices like diskettes, USB sticks, etc.
The licenses and CDs are usually sold by software
vendors. Since this type of software is installed on
the premises (in the building) of the users rather
than on a remote facility, it also commonly known
as ‘on-premise software’. Also, because this type
of software has been used for ages compared to
the new software phenomenon, it is also known
as traditional software.
The Internet boom in the mid-1990s has shifted
the way in which companies - including software
vendors - are doing business. The Internet has
become not only the medium for marketing their
software, but also turned out to be the major re-
quirement to deliver their software. In other words,
without the existence of an Internet connection,
this new type of software cannot be utilized by
their customers. This new phenomenon began in
the late 1990s with the concept of Application
Service Provider (ASP), which has evolved into
another software hype, most popularly known as
‘Software as a Service’ or SaaS (Hoch et al., 2001).
156
Software as a Service and the Pricing Strategy for Vendors
The trend towards SaaS has been predicted by Rust
and Kannan (2003) as early as 2003 when they
still called it ‘e-service’. In SaaS, customers have
the freedom to use the software as they require.
Hence, SaaS is often referred to as ‘on-demand’
software. SaaS applications are being installed in
data centers and no longer delivered as a product
(physical object), but as a service. This fact has
become the reason why the term ‘product’ does
not fit any longer in the world of SaaS. The term
‘solution’ is being used instead.
In rough economic times like those seen today,
the SaaS adoption rate for 2009 has been increas-
ing dramatically from 36% to 42% over 2008
(Mahowald, 2009). This is happening because
the customers want to perform reasonable cost
cutting without affecting the efficiency of their
business operations. Adopting SaaS solutions has
been the more favorable alternative rather than
investing in completely new on-premise software
or in outsourcing.
At present, there are many definitions for SaaS
from different sources and some of them even refer
to SaaS using other terms. For example, the term
‘E-services’ was introduced by Rust and Kannan
(2003) and ‘Software Oriented Computing (SOC)’
was brought by Papazoglou (2003). Besides these
different terms, many people are still misunder-
standing the concept of SaaS. These facts have
motivated us to make a base-definition from the
diverse available literature which could assist us
in our research and to provide our readers with a
more clear definition of SaaS.
Subsequently, in order to come up with this
definition, we have selected twelve different
published articles. The literature is comprised of
seven scientific and five business studies. The
base definition is set out from the similar elements
stated in each article. The following table describes
all important elements of SaaS definitions which
are explicitly stated in these studies.
On Table 1, the most stated and important
elements are highlighted in gray. And based on
these results, the following base-definition is
generated:
“SaaS is a software delivery model that supports
multi-tenancy in which the vendors host and
operate their software on a data center (either
independently or through third-party) and provide
it to their customers over the Internet and typically
on a subscription basis and/or pay-for-use basis.”
The term ‘SaaS vendor’ is used for the company
who builds and develops the software while ‘SaaS
provider’ is used for the third party company who
provides the infrastructure in order to ensure that
the software from the vendor is properly delivered
as a service to end users.
Related to the definition above, researchers
have categorized the two main scenarios regard-
ing how the software and money cycle for SaaS
is currently in the market. The first scenario is
when the company develops, hosts and operates
their software on their own data center or infra-
structure. In this case, the term SaaS vendor is also
applied to this company although they act both as
vendor and provider. And for the second scenario,
the company hosts and operates their software
via SaaS provider (third party). The illustration
of these two scenarios can be found in Figure 1.
Based on the matrix table in the previous section
and the supporting literature, we have listed several
key principles or main characteristics of SaaS in
order to help readers understand its concept. The
principles are:
• The architecture of SaaS has been designed
to support multi-tenancy where one cong-
uration code base can support multiple dif-
ferent customers, allowing them to share
all resources including databases (Carraro
157
Software as a Service and the Pricing Strategy for Vendors
& Chong, 2006; Tarzey et al., 2007). Many
articles, especially from the business per-
spective, tend to skip this principle and
focus more on the other benets of SaaS.
Many business people think that the multi-
tenancy helps the economics but does not
do anything for the customer. However,
this multi-tenancy is the most signicant
key for SaaS since it makes SaaS differ-
ent from other online applications such as
ASP.
• The SaaS offerings are scalable; they are
easily scaled up or down depending on
the demand from customers (Carraro &
Chong, 2006; Chou & Chou, 2008; Tarzey
et al., 2007). Customers have the freedom
to change their usage of the SaaS solu-
tions within a certain period of time. For
instance, customer X required 30 users last
month to operate a certain SaaS offering,
but because many of their employees are
currently on summer vacation, this cus-
tomer changed its usage to only 15 users
for the next two months.
• The applications are hosted and installed
at a site the vendor has chosen (internal
or via third party provider) (Accenture,
2008a; Blokdijk, 2008; Carraro & Chong,
2006; IBM, 2008; Kaplan, 2009; Merchant
& Geisman, 2006).
• Activities are managed in data cen-
ters rather than at the customer’s site
Table 1. A matrix of SaaS definitions
Sources
Elements
Ac-
centure
(2008a)
Blok-
dijk
(2008)
Car-
raro
and
Chong
(2006)
Chou
and
Chou
(2008)
Greschler
and
Mangan
(2002)
Hoch,
et al.
(2001)
IBM
(2008)
Ka-
plan
(2009)
Kittlaus
and
Clough
(2009)
Rayner
(2008)
Sääk-
sjärvi,
et al.
(2005)
Ses-
sions
(2006)
Number
of
Elements
Base
-
defi-
ni-
tion
Software model x x - x x x x - x x - - 8 x
Software approach - - - - - - - - - - - x 1 -
Software solution - - - - - - - x - - - - 1 -
Remotely access
(Internet based) x x x x - x x x x x x - 10 x
Managed by providers x x - - - x - x - x - - 5 x
Hosted service x x x x x x x x - - x x 10 x
Subscription basis,
recurring fee x - x - x - x x - - 5 x
Usage metric - - - - - - - - x x - - 2 -
Pay for use x x - x - - - - x x - x 6 x
Configurability - - x - - - - - - - - - 1 -
Multi-tenancy - - x - - - - - - x - - 2 x
Scalability - - x - - - - - - - - - 1 -
Developed by vendors x - - - - - x - - - - - 2 -
Data center/server x x - - x x - - - - x - 5 x
Internal or external
data center/ third party x - - - x - - - - - - - 2 x
Time & location
independent - - - - - - - - - - x - 1 -
Attractive payment - - - - - - - - - - x - 1 -
On-demand installa-
tion & maintenance
(support)
- - - - x - - x x - x x 5 x
No cost (advertise-
ment model) - - - - - - - - x - - - 1 -
158
Software as a Service and the Pricing Strategy for Vendors
(Accenture, 2008a; Blokdijk, 2008;
Greschler & Mangan, 2006; Hoch et al.,
2001; Sääksjärvi et al.,2005).
• SaaS enables the customers to access
the applications remotely via the Web
at anytime and anywhere (Dym, 2009;
Lassila, 2006; Rowell, 2009; Sääksjärvi et
al.,2005). Thus, an Internet connection is
a mandatory requirement to be able to use
the applications.
• SaaS vendors control the upgrades of the
application, which eradicates the need for
customers to download patches and up-
grades (Caldwell & Eid, 2007; Hoogvliet,
2008; Kaplan, 2009; Lassila, 2006).
• In most cases, the upgrades are done
more frequently, and in smaller releases,
rather than in one big release as it is nor-
mally done with on-premise applications
(Geisman, 2008). Since the vendor has
full control over the installed applications,
they have the tendency to upgrade their
applications and x the bugs more often
from their data centers.
• Customers are always working with
the latest version of the application
(Accenture, 2008a; Choudary, 2007;
Hoogvliet, 2008; Mahowald, 2009;
Rowell, 2009).
• The responsibility for technical infra-
structure including their cost is allocated
from customers to provider. Therefore,
the provider controls the upgrades of the
back end system (operating system, hard-
ware, network, etc.) and is responsible
for maintaining and xing any failures
of infrastructure, if it happens (Caldwell
& Eid, 2007; Hoch et al., 2001; Lassila,
2006; Mahowald, 2009; Pring et al, 2007;
Sääksjärvi et al.,2005; Sysmans, 2006;
Tarzey et al., 2007).
• Customers are no longer the ‘owner’ of
the application, but ‘rent’ the service of
the applications (Chou & Chou, 2008;
Hoch et al., 2001; Merchant & Geisman,
2006). The customers do not need to buy
the licensing to use the applications any-
Figure 1. On-premise vs. software as a service
159
Software as a Service and the Pricing Strategy for Vendors
more. The applications are owned only by
the vendors.
• Customers are charged using a subscrip-
tion (xed fee) model: monthly, quarterly,
or annually; usage-based pricing based on
metrics, and no costs with embedded ad-
vertisement like Google (Blokdijk, 2008;
Chou & Chou, 2008; Hoch et al., 2001;
Kaplan, 2009; Kittlaus & Clough, 2009;
Rayner, 2008; Sysmans, 2006; Wang,
2009). Nevertheless, there are always pos-
sibilities that SaaS vendors might come
up with new charging alternatives in the
future.
• SaaS is frequently integrated into a larger
network of communicating software - ei-
ther as part of a mash up or as a plug-in to
a platform as a service. Hence, additional
skills and efforts are absolutely required
to do it.
The aforementioned main characteristics of
SaaS are also useful to differentiate between SaaS
solutions and on-premise software in the market.
On-premise software is installed on the customer
side while for SaaS it is are installed in data cen-
ters. This is shown in the following figure where
software and data are placed in a separate box for
on-premise and not in the case of SaaS. Referring
to the earlier base definition for SaaS, software and
data can be installed either in the infrastructure
of the SaaS vendor (scenario A) or through the
third party or SaaS provider (scenario B). These
two scenarios are chosen since they are the most
common situations for SaaS.
In addition, Table 2 provides detailed informa-
tion about the different essential aspects of on-
premise and SaaS. The information is collected
from different sources such as Accenture (2008b),
Kittlaus and Clough (2009), Pring et al. (2007),
Sysmans (2006), Tarzey et al. (2007), Wilson and
Basiliere (2008), and lastly York (2008).
As a new hype in the market, many people are
still puzzled by how SaaS is related with other
technologies. This section will provide a better
explanation about its relationship with Cloud
computing, Web 2.0, its predecessor – ASP, and
Software + Service.
Cloud Computing has been a dominant buzzword
in the IT industry for some time. This term refers
to any virtualized resources that are delivered as
a service from data centers over the Internet and
accessible from anywhere in the world (Lin, et
al., 2009; Armbrust et al., 2009; Buyya et, al.,
2008; Hayes, 2008; Vouk; 2008). All data and
software applications that were originally located
on desktop and corporate server rooms are being
swept up and installed in “the cloud” or online
resources. According to Lin et al. (2009), Cisco,
one of the global leading suppliers of network-
ing equipment and network management for the
Internet, sees virtualization and automation as the
key enabling technologies of cloud computing.
A cloud is categorized as Private Cloud or
Public Cloud based on the location of the data
center where the services are being virtualized.
For private cloud, the data center is built inter-
nally behind a firewall and not shared outside
the enterprise. Full control is retained by the
organization. On the contrary, in public cloud,
the service providers manage the infrastructure
and offer public customers the ability to deploy
and consume services over the Internet (Armbrust
et al., 2008).
The cloud-based services are not only restricted
to applications, or what is called “Software as a
Service”, but could also be the platform and the
hardware (infrastructure). For example, Google
160
Software as a Service and the Pricing Strategy for Vendors
App Engine offers the users a complete develop-
ment stack that uses familiar technologies to build
and host Web-based applications; Amazon Elastic
Compute Cloud (EC2) and Amazon Simple Stor-
age Service (S3) provide the users with the ability
to resize the capacity like bandwidth, processor
and storage required for running their applications.
Here, the users are mostly the software developers
who implement their applications for, and deploy
them in, the cloud (Youseff et al., 2008).
From the service type and its architectural
point of view, Creeger (2009), Lenk et al. (2009),
Lin et al., (2009), and Vaquero, et al. (2009) have
distinguished three layers of cloud computing:
SaaS, PaaS, and IaaS. The illustration of these
groups can be found in Figure 2.
1. Software as a Service (SaaS): Since this is
the subject of this research, a more detailed
explanation about it can be found in other
sections of this chapter. Some examples are
Google Apps, Microsoft Office Live (office
application), Salesforce.com (CRM applica-
tion, Workday (HRM application), and
NetSuite (accounting application).
2. Platform as a Service (PaaS): This is the
application development platform that
enables the runtime environment for cloud
applications. The providers supply the users
(developers) with a programming-language-
level environment with a set of well-defined
APIs to facilitate the interaction between the
environment and the cloud applications, as
Table 2. On-premise vs. software as a service
On-premise SaaS
Model
Software is delivered to customers for installation on the custom-
ers’ computers. They are accessed on-site.
Unless contracted separately, customers are typically responsible
for installation, maintenance, access time, hardware performance,
and applying any updates after receiving updated software from
licensor via download or disk.
The customers require in-house expertise in all technical aspects.
Slow to deploy.
The architecture model is more complex since there might be dif-
ferent code bases for different systems. E.g. different installation
files for different OS.
Ownership
Ownership of the intellectual property assets belong to the vendors
(licensors). Customers receive a physical copy of software (usually
available with the code).
Pricing and Licensing Method
The customers need a license, which includes the pricing model in
order to use the software.
Mostly is sold with fixed one-time fee or perpetual license.
Warranty
Warranty of compliance with documentation or system specifica-
tions usually runs for a period of time (90-180 days), which ex-
pires afterwards. Any further problems are handled under separate
maintenance contract.
Migration
It could be a compatibility issue of data migration on certain soft-
ware and operating systems.
The switching procedures require additional costs and efforts.
Marketing and Finance
Typically is sold for niche focus and used in low volume.
On-premise software is typically counted as assets (capital ex-
penses) and has bigger financial risk for the customers.
Model
Software is accessed online (via Web) and installed in data centers
chosen by the vendors.
The vendors or providers are responsible for installation, mainte-
nance, access time, performance, and updates.
The customers do not require in-house expertise in the technical
aspects.
Faster and less expensive implementations.
The architecture is designed to use one single code base for differ-
ent OS.
Ownership
Ownership and possession of the intellectual property assets belong
to the vendors. The customers rent the software.
Pricing and Licensing Method
The customers need a service contract, not license to use the soft-
ware. Pricing model is also applied to SaaS offerings.
The software is typically sold in subscription based (monthly, quar-
terly, annually, etc) and/or usage based on several metrics.
Warranty
All support, training, security risks are mostly included in SaaS
fees. Customers will often have the option to discontinue using the
software if service does not significantly comply with documenta-
tion. The refund of pre-paid fees is usually not available.
Migration
Typically not an issue because software is designed already to be
compatible with many different operating systems.
The switching procedure is relatively quicker and simpler.
Marketing and Finance
The software is sold for mass market and used in high volume.
SaaS cannot be counted as assets on a balance sheet because it is
considered more as operational expenses (opex), which of course
has a smaller risk of investment.
161
Software as a Service and the Pricing Strategy for Vendors
well as to accelerate the deployment and
support the scalability needed for those cloud
applications (Youseff et al., 2008). In order to
enable this environment, the providers must
ensure that the operating system and the sup-
ported application server stack are installed.
These application server stacks might be a
software bundle used for languages like Perl,
Python or PHP, Ruby on Rails for Ruby, and
Tomcat for Java (Zhen, 2008). Examples
of PaaS are Google App Engine and Force.
com. Google App Engine provides a Python
and Java runtime environment together
with the APIs for applications to interact
with Google’s cloud environment (Google,
2009). Force.com offers the Apex language
that allows the developers to design, along
with their applications’ logic, page layout,
workflow, and customer reports (Salesforce.
com, 2008). To have a better visualization,
we can think of PaaS that runs the software
like MS Visual Studio to compile and to
run a Web page. Instead of being used to
deliver the cloud applications, PaaS can also
be used as a way to integrate different SaaS
applications (Giurata, 2008).
3. Infrastructure as a Service (IaaS): IaaS
makes it easy for the developers to provi-
sion resources such as servers, connections,
storage, and related tools (firewalls, routers,
switches) in order to build a cloud application
environment from scratch. It was previously
known as Hardware as a Service (HaaS),
which was first coined by Carr (2006). IaaS
can be seen as having a data-center-in-the-
cloud, which underlies the infrastructure of
PaaS and SaaS.
Virtualization becomes the enabling technol-
ogy for IaaS that allows the users unprecedented
flexibility in configuring their settings while
protecting the physical resources of the providers’
data center (Youseff, et al., 2008). Some examples
are Amazon Web Services S3 and EC2, Terre-
Figure 2. Ontology of cloud computing
162
Software as a Service and the Pricing Strategy for Vendors
mark, Flexiscale, and Rackspace hosting. Cisco
and Microsoft have also stated that virtualization
and automation are the key enabling technologies
of cloud computing (Lin et al., 2009; Microsoft,
2009a).
Referring to the earlier definition of SaaS,
a SaaS vendor may build its own platform and
infrastructure to support its SaaS solution, or
outsource it to the providers. In this case the PaaS
companies are the providers. The same situation
occurs for these PaaS companies. They can also
build their own infrastructure or outsource it by
making use of the available IaaS in the market.
According to Knol et al. (2008) and Barnatt
(2008), Web 2.0 involves making new improved
forms of online connection between two or more
people (interpersonal computing), two or more
online services (Web services), and between the
individual user and software applications (software
as a service).
Interpersonal computing is about using online
technology to connect people with each other via
social networking sites (Twitter, Facebook, Linke-
dIn, etc.), wikis, blogs, and online videos. Web
services are components of online functionality
which can be plugged together in order to create
integrated online offering or mash-up. The devel-
opers are now using various Web APIs to create
mash-ups to solve all types of problems from
integrating the online payment service PayPal
with other websites to the esoteric mash-ups that
record the location of an object (Maximilien et
al., 2008). As the final aspect of Web 2.0, SaaS
is changing the way people use software and
freeing users from the burden of installation and
maintenance of the software. Web 2.0 also allows
the creation of a new business models such as
AdWords, AdSense, Analytics, Map for Google.
In conclusion, SaaS is just a part of the large
picture of Web 2.0 and Cloud Computing, which
are the continuing evolution of how we exploit
the Internet and computer applications in general
(Danielson, 2007; Obannon, 2009).
The Application Service Provider (ASP) model be-
came popular in the late 1990s with the emergence
of the first wave Internet enabled application.
Therefore, ASP is considered to be the predecessor
of SaaS that came a few years later. Unfortunately,
many people still think that SaaS is just a new name
for ASP. Even worse, the CEO of Kleinsteen BV
and the project coordinator at KC Beuningen BV
also stated, “there are several companies in the
Netherlands who offer ASP functionalities, but
market them as SaaS”. This approach is actually
a good marketing strategy for these companies,
but consequently, many customers become more
confused with these two terms.
ASP allows the computer applications to be
hosted remotely from the user. The applications
are simply hosted by the provider from a server
farm located at its data center (Walsh, 2003)
without fundamentally changing the architecture
of the applications. Although the costs are spread
over many customers, the hosting cost has still
proved to be too much for ASP to survive in the
market (Hoogvliet, 2008). Additionally, at the
time where ASP was booming, there was only
a small segment of the market that was willing
to outsource their applications. They considered
their applications as a strategic asset that needs
to be kept safe under their own roof (Hoogvliet,
2008). This situation is different from the SaaS
model where the applications are built from scratch
to be Web based applications. A more detailed
overview on the characteristics of ASP and SaaS
can be found in Table 3. These characteristics
are adapted from the article Accenture (2008d),
Kittlaus and Clough (2009), Luit Infotech (2008),
and Tarzey et al. (2007). We believe the aspects
listed in this table describe the major differences
between ASP and SaaS.
163
Software as a Service and the Pricing Strategy for Vendors
Software + Service (S+S) has been seen as a
new way to combine the concept of on-premise
and SaaS to reduce the limitations of both. So,
on-premise users are no longer tied to a certain
device and location where the software is installed
since they can now access the software via cloud
(Internet). In contrast, SaaS users that previously
depended on the Internet connection to use soft-
ware can also do it offline now. The data then will
be automatically synchronized when SaaS users
are connected to the Internet. The term Software
plus Service was first outlined by the Microsoft
Chief Architect, Razy Ozzie, in 2007 (Microsoft,
2009b). Especially due to the privacy concern, a
vendor of S+S may provide their customers options
to move non private to the cloud and sensitive data
can reside locally without losing any software
capability. This seems to bring a win-win situation
for the vendors and their customers. However,
we keep questioning the licensing issue for S+S.
Is this new model going to apply the licensing
principle of on-premise or ‘renting’ SaaS within
their market? Unfortunately, by now we have not
found any clear answers.
Additionally, S+S can also be seen as compli-
mentary to SaaS, which increases the adoption of
S+S. As an example, Google with its Gmail has
adopted S+S by providing the offline capability
through the existence of Google Gears (Clayton,
2009).
Among the three layers listed in the cloud comput-
ing section, SaaS currently has the biggest number
of vendors and has become the most widely used
layer in the market (Ping & Stahlman, 2009). As
a new software model that is now being increas-
ingly adopted, SaaS also conveys several benefits
Table 3. ASP vs. SaaS
ASP SaaS
Model
ASP applications are traditional single-tenant applications but
hosted by a third party who usually do not have specific applica-
tion expertise. The applications are not written as net-native (Web
based) applications.
Quicker to deploy than on-premise, but slower than SaaS.
Access to client is provided via direct connection, or more recently
the Internet, typically through client-server software or remote ac-
cess like Citrix and Microsoft Terminal Services.
The customer (organization) may still need in-house expertise in
the application itself such as installation of the software, separate
hardware, network and security configuration.
The applications are single and usually a highly customized ver-
sion for one customer.
The upgrades are infrequent because the ASPs often depend on the
commercial software suppliers. The upgrades are deployed when
the supplier issued them, usually once a year or less.
Usability
Difficult. Customized version of an already complex application
requires a great amount of training and orientation.
Ownership
Ownership and possession of the intellectual property assets belong
to the vendors (licensor) or the ASP provider in some cases.
IT support
Exclusive, depending on the degree of the customization, addi-
tional maintenance might be required.
Model
SaaS applications are multi-tenant applications, hosted by a vendor
that has all the application expertise and they have been designed
as net-native applications.
Quicker to deploy than ASP.
Access to client is provided via the Internet.
Requires no in-house expertise in the technical aspects to use the
application.
SaaS offers standard software in a multi-user mode that the indi-
vidual customer can only customize to a limited extent. There is
only one code base for all users.
The upgrades are relatively often with small releases since the
applications are only deployed in data centers and made available
to the all users.
Usability
Easier. The users can start using the applications immediately by
utilizing the provided FAQ or demos on the vendor’s site.
Ownership
Ownership and possession of the intellectual property assets
belong to the vendors (licensor).
IT support
Inclusive, IT support becomes part of the service paid by the users.
164
Software as a Service and the Pricing Strategy for Vendors
and risks to the parties who are involved in the
deployment and delivering process of the software.
Based on the SaaS definition and literature review,
we have categorized the benefits and risks into
three different groups: the vendors, the providers,
and the customers (end users). Until now there have
been more studies from the business perspective
than the scientific perspective that discuss these
issues. In fact, many of them talk more about the
benefits of SaaS rather than its risks. Additionally,
we have collected information from our interview
respondents as well.
The benefits listed above are identified from
twelve different studies from both the business
and scientific perspectives. From Table 4 and
additional input from our respondents, the most
discussed benefits of adopting SaaS are described
as follows:
• SaaS enables rapid deployment cycles. The
SaaS architecture model that supports
multi-tenancy, where one conguration
code base supports multiple different us-
ers, allows for easy and rapid deployment
(including: development, integration, im-
plementation, and upgrades process)
(Accenture, 2008c; Dym, 2009; Geisman,
2008; Hoogvliet, 2008; Kaplan, 2009;
Mahowald, 2009; Merchant & Geisman,
2006; Pring et al., 2007; Rowell, 2009;
Sääksjärvi et al., 2005).
• SaaS provides access to the most recent
software version. In SaaS, maintaining the
application becomes the responsibility of
the vendors. The maintenance includes bug
xes and updates where the vendors install
the patches or releases in their data centers.
As a result, the users are assured that they
all are always using the same and up-to-
date version of the application (Accenture,
2008c; Choudary, 2007, Geisman, 2008;
Hoogvliet, 2008; Kaplan, 2009; Lassila,
2006; Mahowald, 2009; Merchant &
Geisman, 2006; Rowell, 2009; Sääksjärvi
et al., 2005).
• SaaS offers payment exibility. The ‘pay-
as-you-go’ pricing model that comes with
SaaS has brought exibility to customers.
This model allows them to scale their us-
age up and down and to pay for it as a re-
curring fee (Geisman, 2008; Kaplan, 2009;
Mahowald, 2009; Merchant and Geisman,
2006; Pring et al., 2007; Rowell, 2009;
Sääksjärvi et al., 2005).
• SaaS application is accessible anytime
and from anyplace via any devices with an
Internet connection. Because SaaS appli-
cations are Web based and installed in data
centers (not in the users’ site), the users can
utilize them from wherever and whenever
they want to. They only need to ensure
that they have an Internet connection to
access the applications from their devices
such as desktop, notebook, PDA, or mo-
bile phone (Accenture, 2008c; Dym, 2009;
Hoogvliet, 2008; Lassila, 2006; Rowell,
2009; Sääksjärvi et al., 2005).
• SaaS requires lower up-front investment
for infrastructure (hardware) and opera-
tional management (maintenance staff).
Customers are not required to invest in
hardware or additional IT staff in order
to use SaaS applications. It is now the re-
sponsibility of the vendors to do so. And
for an exchange, customers need to pay
a recurring fee for using the application
including some additional benets such
as maintenance and support (Accenture,
2008c; Choudary; 2007; Kaplan; 2009;
Mahowald, 2009; Pring et al., 2007;
Sääksjärvi et al., 2005).
• More predictable cash ows (in-out cash).
In most cases, the costs of using applica-
tions, which is paid by customers, are
relatively the same in every period. The
165
Software as a Service and the Pricing Strategy for Vendors
Table 4. The SaaS benefits matrix
Benefits Accenture
(2008c)
Choudhary
(2007)
Dym
(2009)
Geis-
man
(2008)
Hoogv-
liet
(2008)
Ka-
plan
(2009)
Lassila
(2006)
Ma-
howald
(2009)
Mer-
chant
and
Geis-
man
(2006)
Pring
et al.
(2007)
Rowell
(2009)
Sääk-
sjärvi
et al.
(2005)
Occur-
rence
SaaS enables rapid deployment cycles (development, integra-
tion, implementation, and upgrades) x - x x x x - x x x x x 10
SaaS allows to focus on more strategic projects (core compe-
tency) - - x - x x x - - - - x 5
SaaS provides access with the most recent version of the ap-
plication x x - x x x x x x - x x 10
SaaS application is accessible from anytime & anyplace via any
devices with internet connection x - x - x - x - - - x x 6
SaaS requires lower up investment for infrastructure (hardware)
& operational management (maintenance staff) x x -- -x-x-x-x6
SaaS offers less risky investment x - - x x x - - - - - - 4
When it is succeeded in integrating into SaaS offering, the
bargaining power/competitive differentiation of companies will
be increased
- x x - - - x - - - - x 4
More predictable cash flows (in-out cash) - x x - x - x - - - x x 6
SaaS offers payment flexibility - - - x - x - x x x x x 7
SaaS users and/or companies can achieve greater profits x x ----------2
Lower initial TCO - - x-x--x-x-x5
Lower production & distribution cost - - x - - - x - - - - x 3
Lower upgrade & maintenance cost - - - - - - x - x x - x 4
Lower switching cost - - - - - - - - x x - - 2
Effective low cost marketing - - x---------1
Increased total available market - - x - - - - - x - x - 3
Quicker & easier to market - - x - x - - - - - - - 2
Expands the potential customer base - - - - - - x - - - - x 2
Improved customer relationship - - x-x-- -x-x-4
Faster time to value - - - x x - - - x - - - 3
continued on following page
166
Software as a Service and the Pricing Strategy for Vendors
same situation applies to SaaS companies
(vendors and/or providers), which receive
relatively the same revenues. This fact
conveys a better overview and more pre-
dictable cash ow both for customers and
SaaS companies (Choudary, 2007; Dym,
2009; Hoogvliet, 2008; Lassila, 2006;
Rowell, 2009; Sääksjärvi et al., 2005).
• SaaS users and vendors can achieve great-
er prots. Customers who make use of
SaaS software on their business process
can achieve a Return on Investment (ROI)
faster since SaaS is easier and quicker to
implement than on-premise. Next to that,
by having the lower cost of investment,
their ROI will automatically be greater as
well (note: for the same net prots com-
pared to on-premise). The same situation
applies to the SaaS vendors who expend
lower costs for the deployment process of
their software, which includes the develop-
ment, the integration, the implementation,
and the upgrade processes (Accenture,
2008c; Choudary, 2007).
• SaaS expands the potential customer base.
Because SaaS applications have been de-
signed as Web-based applications, it makes
it easier for the vendors to track and ana-
lyze how customers use their applications.
For example, by understanding the features
that are used more or less by their custom-
ers. Such information becomes a vital asset
for the vendors to improve their software
value in the near future (Lassila, 2006;
Sääksjärvi et al., 2005).
The following benefits might be less important
for the vendors, providers, or customers. More-
over, they have not been mentioned in any of the
literature above. However, we assume that they
need to get more attention as well.
• SaaS helps green environment. Compared
to on-premise software, the multi-tenancy
Shortened sales-cycle - - - - - - x - - - - x 2
Feasible to develop new functionalities/ applications for supple-
mentary use - - x - - x - - - - - - 2
SaaS makes it easier and/or less costly to get the required
technical expertise - - - - - - x - - - - x 2
Ability to switch across providers - x ----------1
Freedom to choose (or better software) - - x---------1
Shared responsibility for support infrastructure - - --x-------1
Encourage more standard IT - - -----x----1
Simplify sharing system/ information - - -----x----1
More stable security - - --x-------1
Number of benefits issued in each article 6 6 13 5 12 7 10 7 8 6 7 14
-=not applied x = applied
Table 4. Continued
167
Software as a Service and the Pricing Strategy for Vendors
model of SaaS has signicantly reduced
the number of physical infrastructures
needed to support the software, both in
data centers and on the customer site. The
less infrasctructure is used, the less polu-
tion that is created. Besides that, all the
contracts, factuurs, and other legal agree-
ments, which were previously printed on
paper, are now accessible online and can
be more easily analysed. These facts has
shown us how SaaS can support the green
environment to reduce the effects of global
warming. So far, only one book by Schulz
(2009) has been found that addresses this
issue.
• SaaS minimizes software piracy. The trans-
formation from analog to digital in the
early 1980s in line with the proliferation
of computers and the Internet have made it
much easier to make and distribute digital
copies. For on-premise software, custom-
ers receive the installation le, perhaps on
CDs or any other format before they can
make use of the software. Since they have
access to the software le, it allows ‘smart’
people to track the code to nd ways to ille-
gally duplicate it without paying anything,
or even produce and resell their own ver-
sion of the software. This software piracy
has created a huge loss in the software in-
dustry. During the ve year period (1994 –
1998), the loss has already approached $60
billion (Moores & Dhillon, 2000). Since
SaaS applications are installed in data cen-
ters where customers do not have direct ac-
cess to the source code for the software, it
can certainly minimize the current piracy
activities in the market. So far, only studies
like Moore and Mahmoud (2009) discuss
this particular benet.
Table 5 describes the benefits received by
vendors, providers, and end users.
In reality, the implementation of SaaS has also
created some risks or challenges for vendors,
providers, and also end users. Therefore, by using
a similar approach as above, we have listed several
risks or challenges in adopting SaaS in Table 6.
Up until now, there is less literature that dis-
cusses the risks of adopting the SaaS model
compared with its benefits. Hence, we have in-
cluded eight additional studies to be further ana-
lyzed as listed in Table 6. From the table, and
input from several of our respondents, the follow-
ing risks are commonly discussed:
• Security and privacy. Many customers,
especially the enterprises, are still vigilant
to put their data off premise, which means
that they will lose direct control of their
data. They are still questioning the privacy
and the procedures provided by SaaS ven-
dors to cope with security vulnerabilities
such as hardware failure, power failure, or
disasters like re and ood (Caldwell &
Eid, 2007; Hayes, 2008; Lin et al., 2009;
Merchant & Geisman, 2006; Pring et al.,
2007; Sääksjärvi et al., 2005; Tarzey et al.,
2007; Wang, 2009).
• Reliability and performance. Depending
on the technical solution used by the ven-
dor or the provider to deliver their SaaS
solutions, the reliability and performance
issues often become challenges. For ex-
ample, the compatibility on different oper-
ating systems and Web browsers, and the
latency resulted from the hardware used in
the infrastructure (Hayes, 2008; Lassila,
2006; Lin et al., 2009; Sääksjärvi et al.,
2005).
• Integration among PaaS platforms and
other SaaS applications (interoperabil-
ity). Since the SaaS model architecture is
a complex network, and users do not have
access to the software code, it makes the
168
Software as a Service and the Pricing Strategy for Vendors
Table 5. The benefits of SaaS for vendors, providers, and end Users
Benefits SaaS vendors SaaS providers End Users
SaaS enables rapid deployment cycles (development,
integration, implementation, and upgrades) x x x
SaaS allows to focus on more strategic projects (core
competency) x 0 x
SaaS provides access with the most recent version of
the application 0 0 x
SaaS application is accessible from anytime & any-
place via any devices with internet connection 0 0 x
SaaS requires lower up investment for infrastructure
(hardware) & operational management (maintenance
staff)
x x x
SaaS offers less risky investment / failed of deploy-
ment 0 0 x
When it is succeeded in integrating into SaaS offer-
ing, the bargaining power/competitive differentiation
of companies will be increased
x x x
More predictable cash flows (in-out cash) x x x
SaaS offers payment flexibility, which is preferred by
the customers 0 0 x
SaaS users and/or companies can achieve greater ROI
(because of lower investments) x x x
Lower initial Total Cost of Ownership (TCO) x x x
Lower production & distribution cost x x 0
Lower upgrade & maintenance cost x x x
(free in most cases)
Lower switching cost x 0 x
Effective low cost marketing x 0 0
Increased total available market x 0 0
Quicker & easier to market x 0 0
Expand the potential customer base x x 0
Improved customer relationship x 0 0
Faster time to value 0 0 x
Shortened sales-cycle x 0 0
Feasible to develop new functionalities/ applications
for
supplementary use
x 0 0
SaaS makes it easier and/or less costly to get the
required
technical expertise
0 0 x
Ability to switch across providers x 0 0
Freedom to choose (or better software) 0 0 x
Encourage more standard IT x x 0
Simplify sharing system/ information x 0 x
continued on following page
169
Software as a Service and the Pricing Strategy for Vendors
integration between the platforms and oth-
er SaaS software much slower and more
difcult (Caldwell & Eid, 2007; Hayes,
2008; Lin et al., 2009; Pring et al., 2007;
Wang, 2009).
• Less tailoring options available for cus-
tomers. In a one-to-many SaaS model,
what users see is what they get. Even
though there are still SaaS vendors that al-
low some customization of data elds and
reports, the software code is not accessible
to end users (Caldwell & Eid, 2007; Hoch
et al., 2001; Merchant & Geisman, 2006;
Pring et al., 2007; Sääksjärvi et al., 2005).
• Required special technical skills for imple-
menting and integrating SaaS applications
(difcult to manage complex network). A
SaaS model with the multi-tenancy as its
key is a complex architecture. Although
there is only one single code base for shar-
ing the resources across multi users, SaaS
vendors must put a tremendous amount of
effort into guaranteeing that the users’ data
is differentiable and will not mixed up with
other user’s data. And for users who de-
mand additional integration for particular
SaaS software with their legacy system or
with some other SaaS software, they will
certainly need the help from special skilled
experts, which also means extra costs for
these users (Caldwell & Eid, 2007; Lassila,
2006; Sääksjärvi et al., 2005). In the world
of SaaS, these skilled experts or compa-
nies are more known as ‘integrator’ or
‘enabler’. More information about these
particular roles can be found in the SaaS
Ecosystem section.
• High initial investment for SaaS vendors
or providers. In order to deliver SaaS soft-
ware, SaaS companies must have the sup-
ported infrastructure ready. Therefore, for
SaaS providers and the vendors that make
use of their own infrastructure, high initial
investment in this infrastructure is inevita-
ble (Lassila, 2006; Sääksjärvi et al., 2005).
• The break-even point will be reached lon-
ger (after few months- years) compared to
on-premise model with its up-front paid
perpetual license. Customers do not buy
SaaS software. Instead, they rent it. The
fee for renting SaaS software is much less
compared to the initial payment the cus-
tomers must pay for on-premise software.
Hence, for SaaS vendors, they have less
revenue in the rst few periods until they
have reached the break-even point (BEP).
When we look at this from the customer’s
perspective, we see a different situation.
Even though there is a higher up-front
cost, it seems after a certain period of time
that on-premise software might be cheaper
than the SaaS subscription model. But, this
Benefits SaaS vendors SaaS providers End Users
More stable security x x x
SaaS helps green environment x x x
SaaS minimizes software piracy x 0 0
Number of benefit issues for different roles 23 12 19
0 = not applied x = applied
Note: When a SaaS vendor uses its own infrastructure to deliver its solutions (do not outsource to third party), then the listed benefits
for SaaS providers on the table above will also apply to this vendor. SaaS vendors can also make use of all the listed benefits to help them
identify the value propositions for their solutions.
Table 5. Continued
170
Software as a Service and the Pricing Strategy for Vendors
Table 6. The SaaS risks matrix
Risks / challenges Hayes
(2008)
Lassila
(2006)
Lin et
al.
(2009)
Merchant
and
Geisman
(2006)
Pring
et al.
(2007)
Sääksjärvi
et al.
(2005)
Tarzey
et al.
(2007)
Wang
(2009) Occurrence
Security & privacy x - x x x x - x 6
Reliability & performance x x x - - x - - 4
Data migration - - x - - - - - 1
Service Level Agreements (SLA) - - - - - - x x 2
Integration among PaaS platforms and other SaaS applications (interoperability) x - x - x - - x 4
For software vendor, the financial burden of hardware & software investment, that previously have been
the burden of their customers (on-premise) - - - - - - x - 1
Managing the expectation of sales staff & resellers - - - - - - x - 1
For vendors who also offering on-premise, it is important to have the alignment of their on-premise &
SaaS pricing - - - - - - x x 2
The break-even point will be reached longer (after few months- years) compared to on-premise with its
front-up paid perpetual license - - - - - - x - 1
SaaS companies should offer multiple pricing options to suit different clients - - - - - - x - 1
Billing not as ‘utility-based’ as customers think. In fact, customers still have to fully pay for some services
that they have used in less volume or even not at all. - - - - x - - - 1
Less tailoring available for the customers - - - x x x - - 3
Lack of competitive differentiation among users of the same SaaS application - - - - x - - - 1
For many enterprise requirement, SaaS functionalities will be too simplistic & crude - - - - x - - - 1
The customization of SaaS applications typically incurs extra costs - x - - - x - - 2
A number of ‘hidden & unexpected’ costs emerging - - - - x - - x 2
Weakened IT management control - - - - x - - - 1
High initial investment for SaaS vendors and/or providers - x - - - x - - 2
The customer is typically bound with a long-term contract (switching costs) in exchange for the lower
price. - - - x - - - - 1
Longer-term TCO uncertainties - - - - x - - - 1
Reduce the application turnover when moving to SaaS model (service fees instead of license & consulta-
tion fees) - x - - - x - - 2
Requires commitment to a more frequent release/upgrade cycle - x - - - x - - 2
Required special technical skills for implementing & integrating the SaaS applications / difficult to man-
age complex network - x - - x x - - 3
Number of risks issued in each article 3 6 5 3 10 8 6 6
- = not applied x = applied
171
Software as a Service and the Pricing Strategy for Vendors
is not going to happen. By referring to the
research of Mahowald (2003), Sysmans
(2006) from SIIA clearly states that “when
people resources and cost of upgrades
are correctly taken in consideration, this
break-even point may never be realized.”
In addition, we have also distinguished the risks
listed in Table 6 into different groups as follows.
Again, when a SaaS vendor makes use of their
own infrastructure to deliver its software, then the
listed risks for SaaS providers in Table 7 will also
apply for this specific vendor. According to Lin et
al. (2009), the risks that currently need significant
improvement for SaaS vendors and providers
are security, performance, and interoperability
issues since they do not currently perform well
in these areas.
A software ecosystem has been increasingly
used in the last decade. It was first described by
Moore (1993) to express the interdependence of
the players in business networks. Kittlaus and
Clough (2009) also defined software ecosystem
in their book as an informal network of (legally
independent) units that have a positive influence
on the economic success of a software product
and benefit from it. A software ecosystem not
only consists of the players, but also of more
informal networks that emerge around important
themes of the software industry such as leading
products, system platforms or new technology
trends (Economides & Katsamakas, 2005; Kittlaus
& Clough, 2009). Jansen et al. (2009) provides
the most comprehensive definition of software
ecosystem (SECO), which is “a set of actors
functioning as a unit and interacting with a shared
market for software and services, together with
the relationships among them”. The scope of a
software ecosystem can be quite broad, depending
on how we look at it.
In order to get a better overview of how SaaS
software is being delivered and the monetary cycle
that goes with it, this research has addressed the
scope of a software ecosystem for five different
key players. These players are the big players that
are mostly involved in any situations for delivering
SaaS software to the customers. The five players
are listed below.
1. SaaS Vendor. This is the company who
develops and builds the SaaS software. To
deliver their software they could use their
own infrastructure independently or host it
for a selected partner.
2. SaaS Provider. This is the external company
that provides the vendor with the infrasctruc-
ture to run and deliver the SaaS software to
the customers (Carraro & Chong, 2006).
SaaS provider is also mostly resposible for
all of the maintenance activities.
3. End users. These are the customers who rent
and make use of the SaaS software. They
could be personal users or enterprises.
4. Reseller. Like on-premise software, for better
market penetration, SaaS vendors also sell
their software using an indirect model via
extended sales channels better known as
‘resellers’ (Murfin, 2005; Schultze, 2007).
Having a partnership with a reseller can
help the vendor to lower their sales cost,
minimize the infrastructure investment, and
lower domain expertise requirements. The
disadvantages for the vendor would be less
profit since they must share it with the reseller
and less control over their customer experi-
ence (Murfin, 2005). However, according
to Chapman (2008), 61% of SaaS vendors
in the current market use direct sales with
their customers and only 11% make use of
a reseller. Depending on the agreement be-
tween the reseller and SaaS vendor, a reseller
might also sell the software under their own
label (better known as ‘white labeling’). So,
172
Software as a Service and the Pricing Strategy for Vendors
Table 7. The risks of SaaS for vendors, providers, and end users
Risks / Challenges SaaS vendors SaaS providers End Users
Security and privacy xxx
Reliability and performance xxx
Data migration x0x
Service Level Agreements (SLA) xxx
Integration among PaaS platforms and other SaaS applica-
tions (interoperability) xxx
For SaaS companies, the financial burden of hardware &
software investment, that previously have been the burden of
their customers (on-premise)
xx0
Managing the expectation of sales staff & resellers xx0
For vendors who also offering on-premise, it is important to
have the alignment of their on-premise & SaaS pricing x00
The break-even point will be reached longer (after few
months- years) compared to on-premise with its front-up paid
perpetual license
xx0
SaaS companies should offer multiple pricing options to suit
different clients x00
Billing not as ‘utility-based’ as customer thinks. In fact, cus-
tomers still have to fully pay for some services that they have
used in less volume or even not at all.
00x
Less tailoring & integration options available for the custom-
ers 00x
Lack of competitive differentiation among users of the same
SaaS application 00x
For many enterprise requirements, SaaS functionalities will
be too simplistic & crude 00x
The customization of SaaS applications typically incurs extra
costs xxx
A number of ‘hidden & unexpected’ costs emerging 00x
Weakened IT management control 00x
High initial investment for SaaS vendors and/or providers xx0
The customer is typically bound with a long-term contract
(switching costs) in exchange for the lower price. 00x
Longer-term TCO uncertainties 00x
Reduces the application turnover when moving to SaaS
model (service fees instead of license & consultation fees) xx0
Requires commitment to a more frequent release/upgrade
cycle xx0
Required special technical skills for implementing & inte-
grating the SaaS applications / difficult to manage complex
network
xxx
Number of risks issued for different roles 15 12 15
0 = not applied x = applied
173
Software as a Service and the Pricing Strategy for Vendors
from the customer’s point of view, it seems
that the reseller is the actual vendor.
5. Integrator. This is for customers, especially
the enterprises that mostly need additional
efforts like customizing the features of SaaS
software to meet their business requirements,
or integrating it with other software (either
on-premise or SaaS) that have been installed
on their system. Since this company enables
SaaS software to be used by the customers
as they want to, this company is also known
as ‘enabler’. The tasks mentioned are not
easy and require special skill to perform it
(Lassila, 2006; Pring et al., 2007; Sääksjärvi
et al., 2005). The integrator is mostly a third
company who has specialized in this area or
a SaaS provider that has skill and experience
to do so. Some of them even provide con-
sulting services to their customers. On the
contrary, in some cases, several IT consulting
companies even become the integrator itself.
From this study and the information collected
from our respondents we have identified six dif-
ferent scenarios for a SaaS ecosystem. These
scenarios depict the current situation in the market
for how SaaS software is being delivered from the
vendor until it becomes accessible to its custom-
ers and also the monetary cycle that goes with it.
The first two scenarios (A and B) are the simplest
scenarios for SaaS without involving any other
parties. These two scenarios are also aligned with
the base definition as described earlier. Regarding
sales and marketing purposes, it is possible that
a vendor applies multiple scenarios.
The vendor develops, hosts, and operates SaaS
software independently by making use of their
own infrastructure (data center) and IT staff. The
software is being directly delivered and sold to the
customer. An example of this scenario would be
Bluedog Ltd., which offers its workbench SaaS
under the support of their own data center. This
workbench is a bundled of SaaS applications,
which is comprised of Content Management Sys-
tem, Customer Relationship Management, Project
and Activity Management, Workflow and Docu-
ment Management System, Learning Management
System, and a few others (Bluedog, 2009).
In this scenario, the vendor develops its software
and hosts it for the selected partner (provider).
The provider supports them with the infrastruc-
ture to enable delivering the software as service
to customers of the vendor. In most cases, all the
maintenance activities such as backup and per-
formance issues become the responsibility of this
provider. As an exchange, the vendor pays them
for those services. Two examples of this scenario
are: 1) Exact Online from Exact Software B.V.,
which is a Dutch SaaS accounting software that
is hosted by KPN CyberCenters (KPN, 2009a).
Figure 3. Scenario A for SaaS ecosystem
174
Software as a Service and the Pricing Strategy for Vendors
Currently this software is only used for the Bel-
gium - Netherland - Luxemburg (Benelux) market.
2) Intacct, as one of the SaaS leaders for financial
management and accounting applications, also
cooperates with IBM data center to operate and
deliver their software (Intacct, 2009a).
In this scenario, besides performing its main
tasks which are supplying and maintaining the
infrastructure to ensure that software from the
vendor runs properly, the SaaS provider also
acts as a ‘reseller’. So, the SaaS provider sells
the vendor’s software to their own customers,
either white labeling or not. In this situation, the
provider and vendor share the percentage of the
revenue received from customers. The amount of
this percentage and the cost burden for the vendors
can be different, depending on the agreement
between both parties. Here, KPN CyberCenters
as the partner of Exact Software, is also being a
reseller of Exact Online. From KPN (2009b), it
is clearly shown that KPN does not white label
the Exact Online.
In some cases, the provider could also act as
‘integrator’ by incorporating SaaS software from
different vendors that are hosted on the infrastruc-
ture and then sell them to their own customers,
either separately or in packages.
This scenario illustrates the existence of a com-
pletely separate reseller to be a partner of a SaaS
vendor. By referring to scenario A and B, we
distinguish this scenario into two categories, D1
and D2. Scenario D1 means that the vendor who
Figure 4. Scenario B for SaaS ecosystem
Figure 5. Scenario C for SaaS ecosystem
175
Software as a Service and the Pricing Strategy for Vendors
owns and controls their infrastructure also has a
partnership with ‘reseller’ to sell their software
(in this situation, the reseller sells under their own
label). And for scenario D2 where the vendor has
already selected a host partner (SaaS provider), it
also partners with third party resellers for their sales
and marketing purpose. Of course, it is important
to have a clear agreement between the vendor and
resellers. A bad agreement may result in loss for
both companies and end their relationship in the
future. A good example of this situation is the
partnership between NetSuite, one of the biggest
global SaaS vendors in the accounting field, who
had an issue with one of its resellers named Sky-
ytek in the beginning of 2009 (Kanaracus, 2009).
This scenario exemplifies the existence of an
‘enabler’, or also known as ‘integrator’, who is
hired by end users. The end users are typically the
enterprises who want to employ particular SaaS
software and integrate and/or modify it to meet
their business requirement (Kittlaus & Clough,
2009). Here, integrating means incorporating the
employed SaaS software with the legacy system of
the enterprise like existing on-premise and other
SaaS software. Modifying means customizing the
functionalities of that software with the requisite
functionalities from the enterprise. In order to
enable this integration and customization process,
the integrator needs direct information from both
vendor and provider. The required information is
depicted as dotted lines in Figure 7. Due to the con-
fidentiality of intellectual properties, additional
agreements among the vendor, the provider, and
the integrator must be applied as well. Referring
to both scenario A and B, we also distinguish
this scenario into two categories, E1 and E2. An
example of this integrator is a company called
‘e-zest’. More information on what they offer to
their clients can be found on E-zest (2009).
The integrator’s revenue is typically a one-time
fee given by the end users as an exchange for the
Figure 6. Scenario D for SaaS ecosystem
176
Software as a Service and the Pricing Strategy for Vendors
service for modifying the SaaS software to meet
the end user’s desires.
Similar to scenario E, this scenario focuses more
on the existence of an integrator to help the end
users implement SaaS software that meets their
business requirements. The only difference is
that the integrator already has partnerships with
the vendors. Therefore, in order to solve the
end users’ problem, the integrator will embrace
the best suited SaaS solution from his business
partners. In most cases, the integrator also gives
consulting service to their end users. For example,
Accenture works together with Salesforce.com in
order to implement CRM solutions for its clients
(Salesforce, 2009a; Stiffler & Bois, 2008). In this
scenario, the integrator does not only receive the
payment from the end users, but also a commission
fee from the vendors. Regarding the location of
infrastructure used to deliver the SaaS software,
we have also divided this scenario into two cat-
egories, F1 and F2.
The aforementioned scenarios (A, B, C, D1
and D2, E1 and E2, F1 and F2) only illustrate the
relationships among certain players: SaaS vendor,
SaaS provider, reseller, integrator, and end users
in the current SaaS market. However, it is pos-
sible that more and more parties are involved in
the near future.
The number of SaaS (Software as a Service) solu-
tions in the market has been rapidly growing in the
last few years. There have been several successful
pioneer SaaS vendors in many different sectors
such as Salesforce in the CRM sector, NetSuite
in the Finance sector, and Workday in the HRM
sector. These big vendors have good experience
Figure 7. Scenario E for SaaS ecosystem
177
Software as a Service and the Pricing Strategy for Vendors
specializing in the kind of software they want to
offer, to which markets, and how they are going
to sell them. Unfortunately, this is not the case for
the small and medium vendors, particularly the
startup SaaS vendors. Many of them have emerged
and then disappeared again in the market. This
is often due to a lack of maturity in their pricing
strategy. Of course, there is no single pricing
strategy that fits best for all vendors because there
are always other factors that also need to be taken
into account.
One of the most important benefits of adopt-
ing SaaS software is the availability of having
more flexible payment methods (Geisman, 2008;
Kaplan, 2009; Mahowald, 2009; Merchant &
Geisman, 2006; Pring et al., 2007; Rowell,
2009; Sääksjärvi et al., 2005). Customers can
be offered the finest payment possibilities while
still maximizing the vendors’ profits, which is
not a trivial task to accomplish. There have been
various pricing issues faced by SaaS vendors in
the market like low sales cycles, low win rates,
chaotic pricing, and difficulty to enter new market
segment (Jones, 2008; Geisman & Nelson, 2008).
Therefore, in order to minimize these issues, the
availability and integration of a good pricing
strategy as part of the overall corporate strategy
for SaaS vendors becomes essential.
SaaS vendors must establish their pricing
strategy before conveying their software solution
to the market. They must be able to understand all
of the potential revenue sources, deployment and
distribution costs of their solution, its ability to
sell them at prices which will allow for maximum
profit, and ensure that the strategy is sustainable
over time so that the vendor can continuously
achieve its objectives (Kittlaus & Cough, 2009).
Hogan and Nagle (2005) also stated that “a
comprehensive pricing strategy is comprised of
multiple layers creating a foundation for price
setting that minimizes erosion and maximizes
profits over time”. These multiple layers become
Figure 8. Scenario F for SaaS ecosystem
178
Software as a Service and the Pricing Strategy for Vendors
the core of the Pricing Strategy Guideline Frame-
work (PSGF). Until now, there have not been any
frameworks in the SaaS research area that provide
the vendors with such a pricing guideline. Hence,
we have constructed this framework as a solution
that provides SaaS vendors with a guideline to
ensure that all the fundamental pricing elements
are included in their pricing strategy. It is intended
for small-to-medium SaaS vendors, particularly
the startup vendors that tend to have less experi-
ence in pricing their SaaS solutions.
The framework has made use of the ‘Strategic
Pricing Pyramid’ by Hogan and Nagle (2005;
2006), ‘Five Forces Model’ by Porter (1985; 2001),
‘Value creation in E-Business’ by Amit and Zott
(2001), several essential SaaS elements from dif-
ferent literature, and some additional input from
our interview respondents. The PSGF framework
is shown in Figure 9 and consists of five layers:
Value Creation, Price Structure, Price and Value
Communication, Price Policy, and Price Level.
To run the business successfully, every company
– including SaaS vendors, in all different sectors
must have a solid corporate strategy. As one of
the business units, the Sales and Marketing unit
is the company’s key source for obtaining more
customers who are willing to buy their products
or services. In other words, these are the custom-
ers that would bring them revenues. For SaaS
vendors, the revenue is generated by charging the
customers for using their solutions. Therefore, it
is important that Sales, Marketing, and Pricing
are collaborated closely.
Figure 9. The pricing strategy guideline framework
179
Software as a Service and the Pricing Strategy for Vendors
Software vendors always expect to set prices
that can capture the value of their solution and that
can also maximize their profits (Hogan & Nagle,
2005). Therefore, it is crucial for the vendors to
have a good understanding of how much value their
SaaS solution can generate for their customers.
And this is indeed not a simple task. The vendor
must be aware of different aspects that influence
the value creation itself, both from internal and/or
external aspects. The former aspect can be identi-
fied from the corporate strategy of the vendors.
And for the latter aspect, the vendors must not
neglect the willingness of their customers, the
existence of alternative solutions, the situation
of their competitors, the new entrants and also
the power of the providers (Porter, 1985; 2001).
We also see that the corporate strategy is inter-
connected with the five forces in Porter’s model.
Within the SaaS market, we also notice that the
bargaining power of the provider becomes less
relevant when the vendors operate their software
on their own infrastructure or when the providers
themselves do not offer additional value compared
to their competitors. For example, a provider who
also acts as a reseller and integrator has more
value compared to a provider that only provides
and maintains the infrastructure. In practice, SaaS
vendors hardly take into account all five competi-
tive sources; instead they are more likely to focus
on several or even only on one source.
The value delivered from a SaaS solution
can also be identified from the four key drivers
of e-business and the linkages among them: ef-
ficiency, complementarities, lock-in, and novelty
(Amit & Zott, 2001). In the context of SaaS,
efficiency may include lowering the transaction
costs, streamlining the inventory management,
and simplifying and speeding up the transaction
processes. Complementarities are presented when
SaaS vendors offer a bundle of solutions together.
The value of lock-in can be achieved because the
vendors have more control over their customers.
Customers have no direct access to the physical
data and are dependent on the format and the of-
fered data export features. Finally, SaaS can also
innovate the ways in which vendors and customers
do their business, called novelty. We notice that
the efficiency and lock-in are the most valued
drivers applied to SaaS.
For SaaS, a business case could be defined as a
financial estimation that compares the associated
costs of deploying a SaaS solution to the quanti-
fied economic benefits or value to be derived
from it within a certain period of time (Kittlaus
& Clough, 2009). It might include the cost price,
price margin, and Return on Investment (ROI)
and some other financial measurements (KPIs)
such as the number of new customers that sign up
every month. We believe that having a concrete
business case becomes essential for SaaS vendors
before pricing their solution. However, it is true
that the business case does not guarantee that the
vendor will achieve exactly the same numbers as
what has been estimated, but it will certainly give
a better financial control for them.
The next step after defining the value creation
and the business case, is determining the pricing
structure for the SaaS solution. It covers how
the vendors are going to charge their customers;
what kind of metrics they must use – especially
when they adopt the usage-based model - and
how the metrics and billing processes are going
to be measured and tracked; how the software
is distributed to the customers; and finally what
kinds of services that they want to provide their
customers that also is included in the Service
Level Agreement (SLA).
Pricing Model
Since SaaS is a new hype in the market, many
people are still confused about pricing and licens-
180
Software as a Service and the Pricing Strategy for Vendors
ing for SaaS. Many consider these two terms to
be basically the same. In the case of SaaS, the
customers do not buy a license but ‘rent’ the soft-
ware. Hence, only the term pricing is applied. The
pricing models that are adopted by SaaS vendors
to charge their customers are mentioned similarly
in different literature (Kaplan, 2009; Kittlaus &
Clough, 2009; Sessions, 2006, Tarzey et al., 2007).
We see that the pricing for SaaS is basically shaped
from one or a combination of the following three
charging alternatives: (1) subscription-based
customers are charged the same fixed-price for
every month, quarter, or year for an independent
usage (Postmus et al., 2008). (2) usage-based
where customers are charged based on their usage
volume from several measurable metrics. This is
the reason why SaaS is also typically paid for on a
“pay-per-use” basis. ‘Price metrics’ are variables
that drive different prices for a single SaaS solu-
tion (Kittlaus & Clough, 2009). The used metrics
might diverge for different solutions, e.g. amount
of data transferred, the time spent by customers
in using the software, number of registered us-
ers accessing the software, number of completed
transactions while using the solution (Ferrante,
2006; Kittlaus & Clough, 2009). The last two
are the most common metrics used in the SaaS
world. Nevertheless, there are still many other
specific metrics that could also be useful for SaaS
vendors, which can be found in Dunham (2009).
(3) advertisement model where customers pay
no cost for using the solution while the vendors
earn the revenue from advertisements of third par-
ties that are embedded on their Web pages. This
model has rarely been applied by SaaS vendors.
The best example is the Google or Yahoo search
engine and Google Apps which includes Gmail as
well (Kittlaus & Clough, 2009; Sessions, 2006).
The most favorable charging alternative in the
current SaaS market is the subscription combined
with the usage-based (number of users) model
(Herbert et al, 2007). Our interviews show that
almost 70% of the respondents have applied a
subscription-based model with the combination
of number of users as the chosen metric. The
remaining respondents are still charging their
customers using only a fixed fee subscription
model. However, it is important to note that it
is possible that the SaaS vendors will come up
with new charging alternatives in the near future.
Billing and Metering System
When formulating the pricing strategy, SaaS
vendors also need to keep in mind the billing
and metering mechanism for the usage of their
solutions. This is a vital element to be able to run
their business properly. They must ensure that
they have accurately charged the single account
of the customers based on the usage amount of
the solution, either for current, previous or future
transactions. A poor billing and metering system
may cause the vendors to lose their customers, as
the customers might feel cheated by the vendors.
This billing and metering system becomes impor-
tant for the vendors to track their customers’ usage
and might also be useful for them to expand the
potential of their customer base, which is useful
input for their future marketing strategy. Hence,
having an accurate metering and billing system
that can handle the mechanism and report overall
usage is crucial. This system must be integrated
with the vendor’s solutions to allow the unifica-
tion of all financial data and system operations
(Blokdijk, 2008; Green et al., 2004). The billing
and metering system can be built in-house or
outsourced to third parties. The in-house systems
tend to provide a better alignment of customer
resource usage to billing because of their ability
to connect to the SaaS platform at more points
and collect more information, but it is a lengthy
development project in most cases. Outsourcing
allows resources to be redirected to the core plat-
form and provides a quicker time to the market,
but reaches fewer points than an in-house system
(Chaudhuri, 2008; Progress Software, 2008).
181
Software as a Service and the Pricing Strategy for Vendors
Software
The choice of how a SaaS solution is being dis-
tributed to customers is also an important element
to be considered by the vendors. Generally, in the
case of SaaS, the solution set can be delivered
separately or in combination of three types: (1)
suite or bundled software of several solutions
provides more value than separated solutions,
which makes it more preferable for the customers
(Bakos & Brynjolfsson, 1999; Dewan & Freimer,
2003) and generates increased sale-revenue for
the vendors. Nowadays, bundling seems to be
the most popular method for the vendors to sell
their software. (2) module, which is a term used
when the vendors sell their solutions separately. In
most cases, vendors will only sell them in modules
when they are assured that their specific solution
has a high-level value and strong competitive
advantage. They believe, even though the price of
their SaaS solution is relatively more expensive,
customers still will be willing to use the software
because they cannot find any better alternatives.
(3) trial. SaaS vendors also offer a no-cost fee for
using their solutions. These solutions are usually
limited by their features and/or limited by a certain
period of time (trial version) such as 14 days or
30 days. The goal of offering this free solution is
to encourage them to use the the paid solution.
In reality, SaaS vendors can employ the
combination between ‘bundled’ and ‘module’
options. For example, vendor ‘XYZ’ sells their
SaaS solution in three different packages (A, B,
and C) and in total, the solution has ten different
modules (1, 2, 3…10). Package A contains module
1, 2, 3, 4 while Package B contains module 2, 3,
5, 6, and 7; and Package C contains module 1, 2,
3, …,7 and 9. Of course, the more value deliv-
ered by the modules contained in a package, the
more expensive the package would be. Figure 10
provides a better view of this package separation.
Vendor ‘XYZ’ offers freedom for their custom-
ers to choose which packages or modules are
best suited with their business needs. So, when
customer only needs module 2 and 5 to support
their business, they can decide to buy the two
modules separately or choose package B only. In
most cases, the accumulated cost of the choices
becomes the main consideration of the customer’s
decision. Please note that it is possible that some
modules are not included in any packages. For
example, in Figure 10, when a customer needs
package A with the additional of module 8 or 10
since these two modules are not included in any
packages. The information about the chosen ap-
proach to distribute the software must be clearly
determined before it can be communicated to the
marketing department.
By adopting the SaaS model, the way the SaaS
vendors provide their services to customers can
also be improved (Hoogvliet, 2008). These ser-
vices are typically included in the fee paid by the
users. The purpose of providing these services is
to help the users with any problems that may oc-
cur when they use SaaS software. From our study
and additional input from the respondents, we
also classify these SaaS services into three types:
(1) real-time support. Besides only providing the
Figure 10. Software packaging example
182
Software as a Service and the Pricing Strategy for Vendors
users with a FAQ, the common contact details of
the vendors such as phone and fax number, email
address, or with a form that needs to be filled out
when they want to ask about their problems, SaaS
vendors can also provide real-time support such
as ‘live chat’. This live chat can be built on the
vendor’s Web site or by taking advantage of the
APIs of online VoIP communication tools like
Skype. Intacct, one of the leading SaaS vendors in
the accounting field, presents a good example by
providing different possibilities to their custom-
ers to contact its support desk (Intacct, 2009). (2)
training. In most cases, depending on the features
of the SaaS solution, a SaaS vendor might also
offer different kinds of training for end users or
administrators. The purpose of having this training
is to inform the users about the different features
of the software and how they can benefit from
these features. The training for the administrator
users usually covers more aspects and needs more
time to complete when compared to the training
for the end users. Training can also be performed
by providing online video. (3) professional
services. For customers who want to get help
from the vendors such as consultancy service to
optimally use the solution to meet their business
requirements or technical assistance to extend
the functionalities from the vendors, some SaaS
vendors also offer professional services. In most
cases, these services will convey additional costs
to those customers or they are already included
in the software package already. A good example
of this service is the Customer Success Manager
(CSM) provided by Salesforce (Salesforce.com,
2009b), which is responsible for analyzing the
users’ behavior and provide added value to their
users by helping them to be more effective and
efficient in using the software according to their
business needs. (Salesforce.com, 2009). CSM
people visit and have meetings with their custom-
ers on a regular basis.
One of the key motivators for moving to SaaS is
the reduction of business risk (Tarzey et al., 2007).
This is identified by the service level agreement
(SLA), which is a contract between a vendor and
its users which specifies the level of service that
is expected during its period. They can specify
the response times for routine and ad hoc queries
and response time for problem resolution such as
network down and machine failure (Hoch et al.,
2001). The aforementioned types of services are
mostly covered within the SLA as well. SLAs can
be very general or extremely detailed, including
the steps to take in the event of a failure. For ex-
ample, if the problem persists after 30 minutes, a
supervisor will be notified; and when the problems
stay after one hour, the account representative
will be contacted.
When the pricing structure including all its ele-
ments has been determined, it becomes the respon-
sibility of the marketing people of the SaaS vendors
to ensure that their prices will be acceptable to the
customers whilst maximizing the profit gained. In
order to make the price acceptable, it is important
that the vendors are able to clearly inform their
customers what the value propositions of their
solution are. A ‘value proposition’ is a business
statement that summarizes why customers should
buy the vendor’s SaaS solution. In addition, the
vendors may also utilize the matrices of SaaS
benefits - risks (Table 4 and 6) to identify the
value proposition of their solutions.
When the vendors cannot communicate this
value clearly, or when the customers do not
completely understand the delivered values of
the solution, then customers tend to think that the
price offered by the vendors is too high (Hogan
& Nagle, 2005). Hence, price and value have a
strong relationship. This is also depicted in our
183
Software as a Service and the Pricing Strategy for Vendors
framework by the arrow that points from the
‘value creation’ level to the ‘price & value com-
munication’ level.
From the marketing research, the marketing
people must already have an estimation of how
much the customers are willing to pay for such
a solution. This is a simple question, but a dif-
ficult and complex one to answer. Furthermore,
they also need excellent approaches to convince
their customers to buy their solution. The infor-
mation related to the features of the solution, the
supported services, and information regarding
the vendor’s background are necessary (Chau,
1995). They need to explicitly list all the included
features and supported services in the different
prices of their SaaS solution. This information
is interrelated with some elements of the pricing
structure layer as well. For example, the ‘pricing
model’ is directly related to the listed different
prices whereas the ‘software’ element is linked
to the features list and the ‘services’ element is
associated to the services list of this third layer.
Examples of the software features, both from
the technical and/or non-technical issues are: the
software functionalities, the availability of be-
ing integrated with existing legacy software, the
compatibility and performance issues in differ-
ent Web browsers, the user friendliness, and the
popularity of the software itself. Furthermore, the
services like the availability of technical support
(24/7 or only during working hours), and end
user training (direct or via online demos) should
be clearly mentioned as well. The different listed
prices, features, and services could also be part of
the value proposition of the vendors.
In the case of SaaS, choosing the right market-
ing channels becomes another important element
to consider. Of course, the old marketing channels
such as brochures, advertisements on confer-
ences or in magazines, are still used by several
vendors. But, we do not see them to be the best
solution anymore. New marketing channels like
online advertisements via Google Ads and new
real-time promotion are becoming more effective
approaches to market the vendors’ solution. The
real-time promotion provides up-to-date informa-
tion to the users such as the new prices, discounts,
or features of SaaS software online. Salesforce.
com is a good example who offers this marketing
channel for their customers.
For the vendors, it is always important to be
honest with their customers about the limitations
of their SaaS solution and also for other services
that are excluded from the listed prices because
this will most definitely affect their reputation
(Hoxmeier, 2000). Other additional sources
that are necessary for their customers are the
references and the past experiences of using that
software from other customers. This information
is commonly found in a case study provided by
SaaS vendors.
Up until this level, the value propositions, the
charging mechanism including the chosen metrics
and billing system, and the alignment between
prices and value have been defined. It is at the
next level when SaaS vendors need to sell and to
close the best deal with their customers. In fact,
even though the SaaS vendors have published
their price list on their website, the prices can
still be altered - especially for customers with a
large number of users (for example, 500 users or
more). These customers may expect and demand
additional benefits from a vendor such as free
set-up costs and purchasing discount (cheaper
price). In order to close the sales and get a signed
agreement appropriately including those addi-
tional benefits, the expertise of sales people of
SaaS vendors is required. These are the people
who have good knowledge and understanding of
what they are selling, to whom they are selling
to, and how they will sell it (Aston, 2009). To
accomplish their tasks, they require information
from the marketing department as well. This is
the reason why a solid relationship between sales
and marketing people in an organization is vital.
184
Software as a Service and the Pricing Strategy for Vendors
This relationship can also be seen in the frame-
work from the position where the pricing and
value communication level is above and directly
connected with the pricing policy.
To sell the SaaS solution, the sales people must
use their best approach or sales mechanism to reach
the customers. There could be different approaches
for different customers. However, there must be
pricing regulation, also known as pricing policy
from the vendors to control what may and may
not be done by their sales people – e.g. a policy
of never giving discounts bigger than 25%. This
is important since the sales people always have
the tendency to give more and more discounts to
customers in order to boost their sales numbers
(Hogan & Nagle, 2005). Pricing policy is also
needed when the vendors have to deal with pric-
ing in order to sell their solutions. In reality, the
vendors may also create price discrimination for
different types of customers, depending on the
level of their usage (Postmus et al., 2008) and
also duration of the contract.
When sales people have reached an agreement
with a customer, then the price margin of the SaaS
solution of that specific customer can be set and
followed by calculating its final unit price. A unit
price is basically the sales price of a SaaS solution
for a specific customer. For SaaS vendors who do
not give additional benefits at all to their custom-
ers, because it is part of their pricing policy, for
example, the listed prices on their websites are
the final unit price and apply to all customers.
Before granting the customer access to their
SaaS solution, it is significant for the vendors to
clearly outline all information on the contract
regarding the prices and any possible additional
benefits, the minimum period of the contract and
the Service Level Agreements.
Software as a Service (SaaS), one of the hot topics
in the software industry today, has been increas-
ingly adopted by many vendors and customers.
This chapter provides an in depth overview of
the state-of-the-art of SaaS, which covers several
aspects of SaaS such as the history, the definition,
the key characteristics, the differences between
SaaS and on-premise software, its relationship
with other technologies, the benefits and risks of
SaaS, and also the different scenarios in the SaaS
ecosystem. In reality, there is no single pricing
strategy that fits all different organizations. From
the literature review and several pricing related
theories, and also the input and feedback from the
interview respondents and experts, we have suc-
cessfully collected different fundamental pricing
elements of SaaS. These elements are the value
drivers (efficiency, complementarities, novelty,
lock-in) of the SaaS solution, which are affected
by the market aspects (external factor) and the
corporate strategy (internal factor); a business case
containing some relevant KPIs like the number of
new customers that sign up every month and ROI;
the different SaaS pricing models that include the
chosen metrics and billing-metering system to
support it; the distribution of the SaaS solution: as
a suite and/or in a separate module, also include
the option to offer trial version; what kinds of
services that are provided to the users on different
prices; the creation of SLA; the chosen marketing
channels to reach the users; and finally, the sales
mechanism that is directly influenced by the ap-
plied pricing policies. The aforementioned factors
are the elements of the Pricing Strategy Guideline
Framework, which has been formulated to help
SaaS vendors to advance their pricing strategy.
Since the PSGF framework contains several funda-
mental pricing elements, it opens the door for other
185
Software as a Service and the Pricing Strategy for Vendors
studies of each of those elements. For example,
research on how to choose the best billing and
metering system, research about the methodology
of selecting the most profitable metrics of SaaS
or the methodology of performing a good SaaS
business case, and research about the available
marketing channels from different SaaS vendors
including the new innovative Customer Success
Manager from Salesforce.com and many others.
Because the PSGF framework elements are pri-
mary, we believe that our framework might apply
not only for SaaS, but also for other Cloud-based
services such as PaaS and IaaS. Consequently,
the incentive to apply the usage-based model for
the PaaS or IaaS vendors becomes bigger, which
of course implies more complex metrics and the
required billing-metering system to support it.
The six scenarios of SaaS have been designed
by taking into account only the five big players,
which are: vendors, providers, resellers, integra-
tors, and end users. In reality, within a SaaS eco-
system, smaller parties are involved as well. As
an example, there are organizations with excellent
experience in laws and other legal issues, who
specialize in constructing the SLA for different
vendors or providers. Therefore, it is definitely
possible to extend these six scenarios.
We found that there are only a few studies that
focus on the benefits of adopting SaaS such as
‘helping the green environment’ and ‘reducing the
software piracy’. Hence, we think that it could be
an interesting topic for other researchers to delve
deeply into these topics.
The presence of Software + Services (S+S),
which allows the users to use the Web-based
software even when they have no Internet connec-
tion, has arrived about one year ago (Microsoft,
2009). We feel that it is a new interesting topic,
which also needs further research. Some aspects
to be considered are the security concerns, the
synchronization process, and the pricing-licensing
issue compared to SaaS.
Accenture (2008a). Software as a Service (SaaS)
Practice. Retrieved February 26, 2009, from Ac-
centure Collaboration database.
Accenture (2008b). Traditional licensing vs. SaaS
(Software as a Service) vs. ASP (Application
Service Provider). Retrieved January 28, 2009,
from Accenture Collaboration database.
Accenture (2008c). SaaS Overview. Retrieved
November 26, 2008, from Accenture Collabora-
tion database.
Amit, R., & Zott, C. (2001). Value creation in e-
business. Strategic Management Journal, 22(6-7),
493–520. doi:10.1002/smj.187
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D.,
Katz, R. H., Konwinski, A., et al. (2009). Above
the Clouds: A Berkeley View of Cloud Comput-
ing. Retrieved February 19, 2009, from http://
www.eecs.berkeley.edu/Pubs/TechRpts/2009/
EECS-2009-28.pdf
Aston, G. (2009). What Is A Sales Strategy?
Retrieved June 28, 2009, from http://www.fresh-
businessthinking.com/business_advice.php?AID
=2668&Title=What+Is+A+Sales+Strategy
Bakos, Y., & Brynjolfsson, E. (1999). Bundling
information goods: Pricing, profits, and effi-
ciency. Management Science, 45(12), 1613–1630.
doi:10.1287/mnsc.45.12.1613
Barnatt, C. (2008). Explaining Web 2.0.
ExplainingComputers.com. Retrieved Octo-
ber 9, 2008, from http://www.youtube.com/
watch?v=7BAXvFdMBWw
Blokdijk, G. (2008). SaaS 100 Success Secrets
- How Companies Successfully Buy, Manage,
Host and Deliver Software as a Service (SaaS).
Brisbane, Australia: Emereo Pty Ltd.
186
Software as a Service and the Pricing Strategy for Vendors
Bluedog (2009). Workbench “Always on
the Job!”. Retrieved March 17, 2009,
from http://www.bluedog.net/wb/93/
wo/90kVL48YV9Ww5MvGIx7Naw/0.5
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J.,
& Brandic, I. (2009, June). Cloud computing and
emerging IT platforms: Vision, hype, and reality
for delivering computing as the 5th utility. Future
Generation Computer Systems, 25(6), 599–616.
doi:10.1016/j.future.2008.12.001
Caldwell, F., & Eid, T. (2007). Is SaaS safe for
financial governance, risk, and compliance solu-
tions. Gartner, Article G00150913. Retrieved
November 13, 2008, from Gartner database.
Carr, N. (2006). Here comes HaaS. Retrieved
October 18, 2008, from http://www.roughtype.
com/archives/2006/03/here_comes_haas.php
Carraro, G., & Chong, F. (2006). Architecture
strategies for catching the long tail. Microsoft.
Retrieved October 4, 2008, from http://msdn.
microsoft.com/en-us/library/aa479069.aspx
Chapman, M. R. (2008). The 2008 Softletter SaaS
Report. Retrieved March 25, 2009, from Softletter.
com database.
Chau, P. Y. K. (1995). Factors used in the selec-
tion of packaged software in small businesses:
Views of owners and managers. Information &
Management, 29(2), 71–78. doi:10.1016/0378-
7206(95)00016-P
Chaudhuri, S. (2008). SaaS pricing and metering.
Retrieved May 20, 2009, from http://sumanchaud-
huri.wordpress.com/2008/02/28/saas-pricing-
and-metering/
Chou, D. C., & Chou, A. Y. (2008). Software as a
service (SaaS) as an outsourcing model: An eco-
nomic analysis. Proceeding of the 39th Southwest
Decision Science Institute Conference, Houston,
Texas. Retrieved October 3, 2008, from http://
www.swdsi.org/swdsi08/paper/SWDSI%20Pro-
ceedings%20Paper%20S469.pdf
Choudary, V. (2007). Software as a service: Impli-
cations for investment in software development.
Proceedings of the 40th Hawaii International Con-
ference on System Sciences, Waikoloa, Hawaii.
Clayton, S. (2009). Google talks software plus
services. Retrieved August 16, 2009, from http://
blogs.msdn.com/stevecla01/archive/2009/01/28/
google-talks-software-plus-services.aspx
Creeger, M. (2009). Cloud computing: An over-
view. ACM Queue; Tomorrow’s Computing Today,
7(5), 1–5.
Danielson, K. (2007). Confusing SaaS with Web
2.0. Retrieved August 28, 2009, from http://
www.ebizq.net/blogs/saasweek/2008/05/confus-
ing_saas_with_web_20/
Dewan, R. M., & Freimer, M. L. (2003). Consum-
ers prefer bundled add-ins. Journal of Management
Information Systems, 20(2), 99–111.
Dunham, M. (2009). SaaS metrics – Saasonom-
ics-101. Retrieved April 1, 2009, from http://
blog.sciodev.com/2009/02/10/saas-metrics-
saasonomics-101/
Dym, R. (2009). Why software as a service?
Helping our customers reduce costs and increase
revenue. OpSource - The Business of Web Opera-
tions database. Retrieved March 22, 2009, from
http://www.opsource.net/saas/wp_why_saas.pdf
E-zest. (2009). E-zest: Company Overview. Re-
trieved August 1, 2009, from http://www.e-zest.
net/technical_consulting.html
Economides, N., & Katsamakas, E. (2005). Linux
vs. Windows: a comparison of application and
platform innovation incentives for open source and
proprietary software platforms. New York Univer-
sity, Law and Economics Research Paper No. 05-
21. Retrieved August, 12, 2009, from http://papers.
ssrn.com/sol3/papers.cfm?abstract_id=822894
Ferrante, D. (2006). Software licensing models:
What’s out there? IT Professional, 8(6), 24–29.
doi:10.1109/MITP.2006.147
187
Software as a Service and the Pricing Strategy for Vendors
Geisman, J. (2008). SaaS pricing for prosperity
[Webinar]. MarketShare, Inc. Retrieved April
16, 2009, from http://www.softwarepricing.com/
readingroom/Content/OpSource%20Pricing%20
for%20Prosperity%20Webinar.pdf
Geisman, J., & Nelson, B. (2008). Pricing a SaaS
product – what’s the big deal? [Webinar]. Pragmat-
icMarketing.com. Retrieved June 01, 2009, from
http://www.pragmaticmarketing.com/resources/
archived-webinars/pricing-a-saas-product-2013-
what2019s-the-big-deal
Giurata, P. (2008). SaaS, PaaS, cloud computing,
on-demand - what do they all mean? Retrieved
October 15, 2008, from http://www.catalystre-
sources.com/saas-blog/saas_paas_cloud_comput-
ing_on_demand_what_do_they_all_mean/
Google. (2009). Run your Web apps on Google’s
infrastructure. Retrieved December 5, 2008, from
http://code.google.com/appengine/
Green, K., Klemenhagen, B., & Hoch, F. (2004).
Software as a service: Changing the paradigm
in the software industry. Software & Informa-
tion Industry Association (SIIA) and TripleTree.
Retrieved January 23, 2009, from http://www.
pangeafoundation.org/pdf/saas_aug04.pdf
Greschler, D., & Mangan, T. (2002). Networking
lessons in delivering ‘software as a service’ – Part
II. International Journal of Network Management,
12(5), 317–321. doi:10.1002/nem.446
Hayes, B. (2008). Cloud computing. Com-
munications of the ACM, 51(7), 9–11.
doi:10.1145/1364782.1364786
Herbert, L., Ross, C.F., Thresher, A., & Bar-
tolomey, F. (2007). The components of SaaS
pricing and negotiations. Forrester Research,
Document # 43581. Retrieved February 20, 2009,
from Forrester database.
Hoch, F., Kerr, M., & Griffith, A. (2001). Software
as a service: strategic backgrounder. Retrieved
October 3, 2008, from http://www.siia.net/estore/
ssb-01.pdf
Hogan, J., & Nagle, T. (2005). What is strategic
pricing? Strategic Pricing Group Insights. Re-
trieved March 15, 2009, from http://www.monitor.
com/Portals/0/MonitorContent/documents/Moni-
tor_What_Is_Strategic_Pricing.pdf
Hogan, J., & Nagle, T. (2006). The Strategy and
Tactics of Pricing: A Guide to Growing More
Profitably (4th ed.). Upper Saddle River, NJ:
Prentice Hall.
Hoogvliet, M. T. (2008). SaaS interface design.
Retrieved April 28, 2009, from http://one3rd.nl/
whitepaper_maartenhoogvliet_saasinterfacede-
sign.pdf
Hoxmeier, J. A. (2000). Software preannounce-
ments and their impact on customers’ perceptions
and vendor reputation. Journal of Management
Information Systems, 17(1), 115–139.
IBM (2008). Making sense of SOA and today’s IT
innovations. IBM Smart SOA solutions. Retrieved
November 20, 2008, from IBM database.
Intacct (2009). Intacct Support. Retrieved on
August 10, 2009, from http://us.intacct.com/
services/support.php
Jansen, S., Brinkkemper, S., & Finkelstein, A.
(2009). Business network management as a sur-
vival strategy: A tale of two software ecosystem.
Proceedings the International Workshop on Soft-
ware Ecosystem (IWESECO 2009), Virginia, USA.
Jones, D. (2008). The five qualities of good soft-
ware pricing. Forrester Research, Document #
46218. Retrieved February 20, 2009, from For-
rester database.
188
Software as a Service and the Pricing Strategy for Vendors
Kanaracus, C. (2009). NetSuite, ex-reseller
locked in ugly legal battle. Techworld. Retrieved
August 1, 2009, from http://www.techworld.com.
au/article/304143/netsuite_ex-reseller_locked_
ugly_legal_battle
Kaplan, J. M. (2009). SaaS movement acceler-
ating. Business Technology Trends & Impacts
Advisory Service Executive Update, 8(22).
Kittlaus, H., & Clough, P. N. (2009). Software
Product Management and Pricing: Key Success
Factors for Software Organizations. Berlin:
Springer.
Knol, P., Spruit, M., & Scheper, W. (2008). Web
2.0 revealed - business model innovation through
social computing. Proceedings of the Seventh AIS
SIGeBIZ Workshop on e-business (WeB 2008),
Paris, France.
KPN. (2009a). Exact Online. Retrieved on Feb-
ruary 26, 2009, from http://zakelijk.kpn.com/
web/file?uuid=d386cdd0-b010-4bd3-b66d-
2e183510674a&owner=3c096f1f-64ae-471a-
a72b-161373c8b70b
KPN. (2009b). KPN Online Boekhouden. Re-
trieved on February 26, 2009, from http://zakelijk.
kpn.com/business/meer-diensten/softwareonline/
alle-software-online/online-boekhouden.htm
Langholz, G., Kandel, A., & Mott, J. L. (1998).
Foundations of digital logic design. Singapore:
Word Scientific Publishing Co. Pte. Ltd.
Lassila, A. (2006).Taking a service-oriented
perspective on software business: How to move
from product business to online service business.
IADIS International Journal on WWW/Internet,
4(1), 70-82.
Lenk, A., Klems, M., Nimis, J., Tai, S., & Sand-
holm, T. What’s inside the cloud? An architectural
map of the cloud landscape. ICSE Workshop on
Software Engineering Challenges of Cloud Com-
puting2009, Vancouver, Canada.
Lin, G., Fu, D., Zhu, J., & Dasmalchi, G. (2009).
Cloud computing: IT as a service. IT Professional,
11(2), 10–13. doi:10.1109/MITP.2009.22
Luit Infotech. (2008). Difference between the ASP
model and the SaaS model. Retrieved November
12, 2008, from http://www.luitinfotech.com/
downloads/saas-asp-difference.pdf
Mahowald, R. P. (2003). Do service providers
deliver value and reduce enterprise costs? IDC.
Retrieved November 5, 2008, from IDC database.
Mahowald, R. P. (2009). SaaS, PaaS, and cloud:
choices for success. Proceedings of the IDC SaaS
Summit Spring 2009, Document # 217935. Re-
trieved April 5, 2009, from IDC database.
Maximilien, E. M., Ranabahu, A., & Gomadam,
K. (2008). An online platform for Web APIs and
service mashups. IEEE Internet Computing, 12(5),
32–43. doi:10.1109/MIC.2008.92
Merchant, N., & Geisman, J. (2006). Solving the
puzzle: pricing, licensing and business models.
Rubicon Consulting, Inc & Market Share, Inc.
Retrieved March 5, 2009, from http://rubicon-
consulting.com/downloads/whitepapers/Rubi-
con_Solving-Puzzle.pdf
Microsoft. (2009a). Cloud computing infrastruc-
ture. Retrieved August 12, 2009, from http://
www.microsoft.com/virtualization/en/us/cloud-
computing.aspx
Microsoft. (2009b). Software + services. The
Architecture Journal, 13. Retrieved August 15,
2009, from MSDN Architecture Center database
via http://msdn.microsoft.com/en-us/architecture/
bb906058.aspx
Moore, B., & Mahmoud, Q. H. (2009). A service
broker and business model for SaaS applications.
Proceedings of the IEEE/ACS International Con-
ference on Computer Systems and Application,
Rabat, Morocco.
189
Software as a Service and the Pricing Strategy for Vendors
Moore, J. F. (1993). Predators and prey: A new
ecology of competition. Harvard Business Review,
71(3), 75–86.
Moores, T., & Dhillon, G. (2000). Software piracy:
A view from Hong Kong. Communications of the
ACM, 43(12), 88–93. doi:10.1145/355112.355129
Murfin, J. (2005). Business case for entering SaaS.
Retrieved August 3, 2009, from Microsoft Solution
for Hosted Messaging and Collaboration database.
Obannon, I. (2009). What Web 2.0, SaaS and cloud
computing mean for tax & accounting profes-
sionals. Retrieved August 28, 2009, from http://
getanewbrowser.com/2006/05/web-20-soa-saas/
Papazoglou, M. (2003). Service-oriented com-
puting: Concepts, characteristics and directions.
Proceedings of the Fourth International Confer-
ence on Web Information System Engineering
(WISE’03), Rome, Italy.
Porter, M. E. (1985). Competitive Advantage:
Creating and Sustaining Superior Performance.
New York: Free Press.
Porter, M. E. (2001). Strategy and the Internet.
Harvard Business Review. Retrieved March 26,
2009, from http://www.soum.com.br/sonaomuda/
ecommerce/Arquivos/Artigos/Strategy_and_the_
internet.pdf
Postmus, D., Wijngaard, J., & Wortmann, H.
(2009). An economic model to compare the prof-
itability of pay-per-use and fixed-fee licensing.
Information and Software Technology, 51(3),
581–588. doi:10.1016/j.infsof.2008.08.004
Pring, B., Desisto, R.P., & Bona, A. (2007). The
cost and benefits of SaaS vs. on-premise deploy-
ment. Gartner, Article G00151171. Retrieved
November 13, 2008, from Gartner database.
Pring, B., & Stahlman, M. (2009). Sizing the cloud:
The world’s first comprehensive cloud computing
services forecast [Webinar]. Gartner. Retrieved
March 19, 2009, from Gartner database.
ProgressSoftware. (2008). SaaS billing & meter-
ing. Progress Software Corporation. Retrieved
May 20, 2009, from http://communities.progress.
com/pcom/servlet/JiveServlet/download/12057-
2-11235/SaaS_BillingMetrics.pdf
Rayner, N. (2008). The impact of SOA and SaaS
on financial systems. Gartner, Article G00157191.
Retrieved November 13, 2008, from Gartner
database.
Rowell, J. (2009). A step-by-step guide to start-
ing up SaaS operations. OpSource – The SaaS
Delivery Experts database. Retrieved March 22,
2009, from http://www.opsource.net/saas/start-
ing_up_saas_operations.pdf
Rust, R. T., & Kannan, P. K. (2003). E-service:
A new paradigm for business in the electronic
environment. Communications of the ACM, 46(6),
36–42. doi:10.1145/777313.777336
Sääksjärvi, M., Lassila, A., & Nordstrom, H.
(2005). Evaluating the software as a service busi-
ness model: From CPU time-sharing to online
innovation sharing. Proceedings of the IADIS
International Conference e-Society 2005, Qawra,
Malta.
Salesforce.com. (2008). Developer Force: Apex
Code. Retrieved December 3, 2008, from http://
wiki.developerforce.com/index.php/Apex
Salesforce.com. (2009a). Contact Partner. Re-
trieved on August 5, 2009, from http://www.
salesforce.com/partners/opportunities/consulting-
partners/profiles/a0x30000000CfKu.jsp
Salesforce.com. (2009b). Job detail of Cus-
tomer Success Manager. Retrieved on August
20, 2009, from http://www.salesforce.com/com-
pany/careers/locations/a0800000000Ab42AAC/
a017000000AIvVJ.jsp
Schultze, A. (2007). Channel Excellence. USA:
Axel Schultze.
190
Software as a Service and the Pricing Strategy for Vendors
Schulz, G. (2009). The Green and Virtual Data
Center. Boca Raton, FL: Auerbach Publications.
doi:10.1201/9781420086676
Sessions, R. (2006). Software as a service: An-
other perspective. The ObjectWatch Newsletter,
52. Retrieved October 3, 2008, from http://www.
objectwatch.com/newsletters/ObjectWatchNews-
letter052.pdf
Stiffler, D., & Bois, R. (2008). Consulting in the
cloud: The emerging SaaS consulting, product
development, and outsourcing ecosystem (Ex-
cerpt). AMR Research, Inc. Retrieved December
2, 2008, from http://www.accenture.com/NR/
rdonlyres/D2BC2C93-38BB-41AB-9F3E-
48B26C91D26C/0/ConsultingintheCloudE-
merginSaaSConsulting.pdf
Sysmans, J. (2006). Software as a service: A
comprehensive look at the total cost of ownership
of software applications. Software & Information
Industry Association (SIIA) database. Retrieved
April 3, 2009, from via http://www.siia.net/estore/
ssb-01.pdf
Takeda, H., Veerkamp, P. J., Tomiyama, T., &
Yoshikawa, H. (1990). Modeling design processes.
AI Magazine, 11(4), 37–48.
Tarzey, B., Longbottom, C., & Stimson, T. (2007).
On-premise to on-demand: The software as a
service opportunity for independent software ven-
dors. Quocirca Insight Report. Retrieved March
22, 2009, from Quaocirca database.
Tukey, J. W. (1958). The teaching of concrete math-
ematics. The American Mathematical Monthly,
65(1), 1–9. doi:10.2307/2310294
Vaquero, L. M., Rodero-Merino, L., Caceres,
J., & Linder, M. (2009). A break in the clouds:
Towards a cloud definition. ACM SIGCOMM
Computer Communication Review, 39(1), 50–55.
doi:10.1145/1496091.1496100
Vouk, M. A. (2008). Cloud computing – issues,
research and implementations. Proceedings of
the 30th International Conference on Informa-
tion Technology Interfaces, Dubrovnik, Croatia.
Walsh, K. R. (2003). Analyzing the application
ASP concept: Technologies, economies, and
strategies. Communications of the ACM, 46(8),
103–107. doi:10.1145/859670.859677
Wang, R. (2009). Shape your apps strategy to
reflect new SaaS licensing and pricing trends.
Forrester Research, Document # 46602. Retrieved
February 28, 2009, from Forrester database.
Wilson, D., & Basiliere, P. (2008). The flavors of
e-procurement extend beyond software as a service
and on-premise. Gartner, Article G00146768.
Retrieved November 13, 2008, from Gartner
database.
Wordreference.com. (2009). WordNet 2.0. Princ-
eton, NJ: Princeton University. Retrieved July
5, 2009, from http://www.wordreference.com/
definition/software
York, J. (2008). Contrasting software-as-a-service
and enterprise software business models. Re-
trieved January 27, 2009, from http://chaotic-flow.
com/2008/09/02/contrasting-software-as-a-ser-
vice-and-enterprise-software-business-models-2/
Youseff, L., Butrico, M., & Da Silva, D. (2008).
Toward a unified ontology of cloud computing.
Proceedings on Grid Computing Environments
Workshop (GCE) 2008, Austin, Texas.
Zhen, J. (2008). Defining SaaS, PaaS, IaaS, etc.
Retrieved November 15, 2008, from http://cloud-
feed.net/2008/06/03/defining-saas-paas-iaas-etc/
Biddick, M. (2010, January 18). Time for a SaaS
strategy. InformationWeek, 1254, 27–32.
191
Software as a Service and the Pricing Strategy for Vendors
Braude, E. (2008). Software-as-a-service and
offshoring. International Journal of Business
Insights & Transformation, 2(1), 93–95.
Campbell-Kelly, M. (2009). Historical reflec-
tions: The rise, fall, and resurrection of software
as a service. Communications of the ACM, 52(5),
28–30. doi:10.1145/1506409.1506419
Choudhary, V. (2007). Comparison of software
quality under perpetual licensing and software
as a service. Journal of Management Information
Systems, 24(2), 141–165. doi:10.2753/MIS0742-
1222240206
Concha, D., Espadas, J., Romero, D., & Molina,
A. (2010). The e-HUB evolution: From a custom
software architecture to a software-as-a-service
implementation. Computers in Industry, 61(2),
145–151. doi:10.1016/j.compind.2009.10.010
Cusumano, M. A. (2007). The changing labyrinth
of software pricing. Communications of the ACM,
50(7), 19–22. doi:10.1145/1272516.1272531
Cusumano, M. A. (2008). The changing software
business: Moving from products to services. Com-
puter, 41(1), 20–27. doi:10.1109/MC.2008.29
Elfatatry, A. (2007). Dealing with change: Compo-
nents versus services. Communications of the ACM,
50(8), 35–39. doi:10.1145/1278201.1278203
Fan, M., Kumar, S., & Whinston, A. B. (2009).
Short-term and long-term competition between
providers of shrink-wrap software and software
as a service. European Journal of Operational
Research, 196(2), 661–671. doi:10.1016/j.
ejor.2008.04.023
Fox, L. (2009). Integrating SaaS and legacy apps:
5 steps for success. NetworkWorld Asia, 5(1), 30.
Greer, M. B. (2009). Software as a Service Inflec-
tion Point: Using Cloud Computing to Achieve
Business Agility. Bloomington, IN: iUniverse.
Hatch, R. (2008). SaaS Architecture, Adoption
and Monetization of SaaS Projects using Best
Practice Service Strategy, Service Design, Service
Transition, Service Operation and Continual Ser-
vice Improvement Processes. Brisbane, Australia:
Emereo Pty Ltd.
Hill, S. Jr. (2008). SaaS seems to favor users more
than vendors. Manufacturing Business Technol-
ogy, 26(1), 48.
Jaisingh, J., See-To, E. W. K., & Tam, K. Y.
(2008). The impact of open source software on the
strategic choices of firms developing proprietary
software. Journal of Management Information
Systems, 25(3), 241–275. doi:10.2753/MIS0742-
1222250307
Keller, E. (2007). How software application pric-
ing models are likely to change. Manufacturing
Business Technology, 25(1), 42–43.
Lamont, J. (2010). SaaS: Integration in the cloud.
KM World, 19(1), 12–22.
Murphy, S., & Samir, W. (2009). ‘In the cloud’
IT creates new opportunities for network service
providers. Journal of Telecommunications Man-
agement, 2(2), 107–120.
Orr, B. (2007). Microsoft begins its radical shift
to software as a service. ABA Banking Journal,
99(12), 46–47.
Postmus, D., Wijngaard, J., & Wortmann, H.
(2009). An economic model to compare the prof-
itability of pay-per-use and fixed-fee licensing.
Information and Software Technology, 51(3),
581–588. doi:10.1016/j.infsof.2008.08.004
Poston, R. S., Kettinger, W. J., & Simon, J. C.
(2009). Managing the vendor set: Achieving best
pricing and quality service in IT outsourcing. MIS
Quarterly Executive, 8(2), 45–58.
192
Software as a Service and the Pricing Strategy for Vendors
Raghu, T. S., Sinha, R., Vinze, A., & Burton, O.
(2009). Willingness to pay in an open source soft-
ware environment. Information Systems Research,
20(2), 218–236. doi:10.1287/isre.1080.0176
Sainio, L.-M., & Marjakoski, E. (2009). The logic
of revenue logic? Strategic and operational levels
of pricing in the context of software business.
Technovation, 29(5), 368–378. doi:10.1016/j.
technovation.2008.10.009
Susarla, A., Barua, A., & Whinston, A. B. (2009).
A transaction cost perspective of the ‘software-
as-a-service’ business model. Journal of Man-
agement Information Systems, 26(2), 205–240.
doi:10.2753/MIS0742-1222260209
Thompson, J. K. (2009). Business intelligence
in a SaaS environment. Business Intelligence
Journal, 14(4), 50–55.
Turner, M., Budgen, D., & Brereton, P. (2003).
Turning software into a service. Computer, 36(10),
38–44. doi:10.1109/MC.2003.1236470
Vorisek, J., & Feuerlicht, G. (2004). Is it the
right time for the enterprise to adopt software-
as-a-service model? Information & Management,
17(3-4), 18–21.
Waters, B. (2005). Software as a service: A look
at the customer benefits. Journal of Digital Asset
Management, 1(1), 32–39. doi:10.1057/palgrave.
dam.3640007
Apex: It is a strongly-typed programming
language that executes on the platform used for
Salesforce.com.
Enabler (or Integrator): A role of IT special-
ist in the implementation of integrated solutions
and effective support of retail systems. It is also
known as Integrator.
Key Performance Indicator (KPI): KPI is a
performance measurement that is commonly used
by an organization to define and to evaluate the
success of their product or service in the market.
Platform as a Service (PaaS): PaaS is the
delivery of a computing platform and solution
stack as a service.
Pricing Strategy Guideline Framework
(PSGF): PSGF is the tentative framework resulted
from the conducted research on this report.
Provider: In SaaS, the provider refers to the
organization which supplies the vendor with the
infrastructure to operate the vendor’s software.
Usually the provider is responsible for the main-
tenance and support.
Reseller: Reseller is an organization that
purchases goods or services with the intention
of reselling rather than consuming or using them.
They are an intermediary between software pro-
ducers (vendor) and end users.
SaaS Ecosystem: A set of actors functioning
as a unit and interacting with a shared market for
software and services, together with the relation-
ships among them.
